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Vorwort 



Die Fachtagung "Expertensysteme '87 - Konzepte und Werkzeuge" ist die erste 
Tagung des German Chapter der ACM zu diesem Themengebiet und eine der 
ersten wissenschaftlichen Fachtagungen in Deutschland, die sich speziell 
mit dieser Wissenschaftsdisziplin befaßt. Im Jahre 1987 erstaunt dies um so 
mehr, als seit dem Auftauchen der ersten Prototypen solcher Systeme Mitte 
der siebziger Jahre, zunächst noch unter der Bezeichnung 
"Produktionssysteme" und "regelbasierte Systeme", bereits über eine Dekade 
vergangen ist. 

Der Begriff "Expertensysteme", der sich zu Beginn der achtziger Jahre auf 
breiter Ebene durchgesetzt hat, manifestiert aber auch einen Wandel der 
Wissensschaftsdisziplin. Während "regelbasierte Systeme" als Studienobjekt 
in der künstlichen Intelligenz und Kognitionswissenschaft auf eine 
langjährige Tradition zurückblicken und letztlich von den durch E.L.Post 
in den vierziger Jahren entwickelten Ersetzungssystemen ihren Ausgang 
nahmen, artikuliert der Begriff "Expertensystem" einen Anspruch, der 
interdisziplinär in die Anwendungsgebiete solcher Systeme hineinreicht. 
Dort im Anwendungsgebiet finden sich nämlich die menschlichen Experten, 
an denen ein "Expertensystem" von seinem Namen her beansprucht, gemessen zu 
werden. Die Stellung solcher Expertensysteme in einer zukünftigen 
"Wissensindustrie" beleuchtet Dr. Hein in seinem eingeladenen Vortrag. 

Aus dieser Situation heraus muß es eines der wesentlichen Anliegen einer 
Fachtagung zum Thema Expertensysteme sein, die Beurteilung des Anspruchs, 
den einen Expertensystem für ein Anwendungsgebiet erhebt, letztlich dem 
fachkundigen Besucher der Tagung bzw. Leser dieses Bandes zu überlassen. 
Das Programmkomitee der Tagung hat sich deshalb bemüht, dem Thema 
Anwendungen breiten Raum zukommen zu lassen. Solche Anwendungen erstrecken 
sich von Expertensystemen zur Unterstützung von Büroaufgaben 
(Appelrath/Ester/ Jasper/Ultsch, Spenke/Bei lken) , der Softwareerstellung 
(Wächter), organisatorischer Planung (Kloth), technischer Konfiguration 
(Lehmann/Normann/Schramm, Cunis/Günter/Syska) und Diagnose 
(Eiben/Eisermann/Fedderwitz, Eichhorn/Pütz/Ziegler) bis hin zu Systemen zur 
Beratung in Vermögensfragen (Martial), der Anwendung neuer Werkstoffe 
(Fehsenfeld/Küke/Langer/Schönwald) und in der Medizin (Klocke/Schecke / 
Jeusfeld/Rau/Hatsky/Kalf ) . Eine Vergleich der Expertensystemtechnologie mit 
der verwandten Technik der Entscheidungstabellen (Güntzer/Schöll/Jüttner / 
Moll) soll die Einschätzung von Expertensystemen abrunden. 



Da aber die dargestellten Anwendungen immer nur den Charakter von 
Beispielen für Expertensysteme besitzen, ist es die heute verfügbare 
Technologie von Expertensystemen, welche die Grenzen des Anspruchs 
solcher Systeme bestimmt. Wesentliche Aspekte dieser Technologie 
charakterisiert Prof. Steels in seinem eingeladenen Vortrag. 




Aktuelle Konzepte in den Bereichen der Wissensakquisition, d.h. der 
Modellbildung und Formalisierung von Wissen (Diederich/ May/Ruhmann, Lutze, 
Riekert) und der Wissensrepräsentation (Beckstein/Görtz/Tielemann, Rathke, 
Beetz, Heyer/Schneider) sowie hierauf aufbauende Werkzeuge (Puppe) bilden 
einen weiteren Schwerpunkt der Tagung. Die Aufgabe der 
Wissensrepräsentation beinhaltet stets auch die Frage, wie effizient das 
repräsentierte Wissen genutzt werden kann. Dies wird am Problem des 
Schlußfolgerns über temporale Gegebenheiten (Hrycey) und der 
Konsistenzprüfung von repräsentiertem Wissen (Mellis) näher untersucht. 
Eine weitere aktuelle Herausforderung bietet der Bereich der dynamischen 
Systeme, der in der klassischen Vorgehensweise (typischerweise) durch 
Differentialgleichungen eine elegante Beschreibung erfahren hat 
( Janson/Sutschet, Di lger/Espen/Schuk) . 

Da sich ein menschlicher Experte nicht zuletzt durch seine Fähigkeit 
auszeichnet, sein Wissen auch mitteilen zu können, muß der 
Erklärungsfähigkeit von Expertensystemen definitionsgemäß eine besondere 
Bedeutung zukommen. Neben technischen Fragen der Berechnung solcher 
Erklärungen (Ladwig/Mellis, Kassel) muß dabei auch untersucht werden, wie 
allgemeine Prinzipien der Gestaltung einer ergonomischen 
Benutzerschnittstelle durch geeignete Softwarearchitekturen realisiert 
werden können (Balzert). Genau wie die Schnittstelle von Expertensystemen 
zum Benutzer (Fehrle), so bedarf auch in anderer Richtung die Schnittstelle 
von Expertensystemen zu konventionellen Anwendungssystemen oder technischen 
Prozessen weitergehender Aufmerksamkeit (Carls). 



Nürnberg, den 12.2.87 
Die Herausgeber 
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KOFIS: ein Expertensystem zur 
integrierten Dokumenten- und Wissensverwaltung 



H.-J. Appelrath, M. Etter, H. Jasper, A. Ultsch 
ETH Zürich 
Institut für Informatik 
CH- 8092 Zürich 



Zusammenfassung 

KOFIS (Knowledge based Off ice Information System) ist ein Expertensystem, das als 
Prototyp eines integrierten Dokumenten- und Wissensverwaltungssystems gestattet, 
Dokumente bzw. Dokumentreferenzen und Wissen über diese Dokumente in Form von 
Termen und Fakten zu bearbeiten sowie regelhaftes Wissen zum Retrieval und zur 
Konsistenzüberwachung bei Updates auszunutzen. Dies geschieht durchgängig auf einer 
einheitlichen Prolog-Basis. Die Schnittstelle zu einem externen Datenverwaltungssystem 
(GridFile) eröffnet Lösungsmöglichkeiten auch für vom Mengengerüst her anspruchsvolle, 
nicht "rein akademische" Aufgabenstellungen. 

Neben dem Anwendungsbezug steht beim Projekt KOFIS die Entwicklung eines 
applikationsneutralen Prolog- Werkzeugkastens (für den KOFIS das z.Zt. zentrale 
Anwendungsbeispiel ist) im Vordeigrund. 

In dieser Arbeit werden zunächst in Kapitel 1 Anforderungsdefinition und Modellierung 
von KOFIS vorgestellt. 

Nach einer Darstellung der wesentlichen Entwurfsentscheidungen für KOFIS in Kapitel 2 
werden in Kapitel 3 einige Implementierungsaspekte einer prototypischen Realisierung des 
Systems auf dem Arbeitsplatzrechner Lilith präsentiert. 



Schlüsselwörter: Prolog, Information Retrieval, Wissensrepräsentation 

CR-Classification: 1.2.1, 1.2.8, H.3.3, H.2.1 



1. Anforderung« definition und Modellierung 



1.1 Objektklassen 

Ziel des anwendungsbezogenen Aspekts des Projekts KOFIS ist die Realisierung eines 
wissensbasierten Einbenutzer-Büro- Informationssystems, das an wissenschaftlichen Büro- 
Arbeitsplätzen - etwa in Hochschulen und Forschungseinrichtungen - einem Benutzer die 
Verwaltung von Dokumenten und "Wissen" erlaubt. 
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Dokumente sind z.B. Artikel aus Fachzeitschriften oder Tagungsbänden, Bücher, Briefe und 
Notizen, die meist in Papierform im Büro abgelegt und dem System über eindeutige 
Standortreferenzen bekannt oder im Rechner als selbsterstellte bzw. über ein Netz empfangene 
Volltexte direkt zugreifbar sind. Die Dokumente sind (logisch) in einer Dokumentenbasis 
zusammengefasst. 

In der Abb. 1 tritt in der Dokumentenbasis beispielhaft ein Artikel mit der Kennzeichnung 
"KOFIS: ein Expertensystem ..." auf, auf den wir auch die nachfolgenden Beispiele beziehen 
werden. 

Wissen besteht aus Termen, Fakten und Regeln. Abb. 1 veranschaulicht dies durch eine 
Faktenbasis (einschl. Terme) und eine Regelbasis , die sich zu einer (persönlichen) 
Wfc s ereb aris ergänzen. 



Dobwxmtmtomrii Pnkt^Wi« 




Abb. 1 Dokumenten- und Wissensbasis 
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1. Terme 

sind Strings über einem vereinbarten Alphabet und repräsentieren Worte und Phrasen aus 
dem Diskursbereich des Benutzers. Terme dienen auch zur eindeutigen Identifizierung von 
Dokumenten und werden in dieser Rolle als DokumentidentiHkator bezeichnet. 

Bsp. 'KOFIS 1 (als Abk. für dieses paper) ist ein Term in der Rolle eines 
Dokumenti denüfikators , der diesen Artikel eindeutig in der Dokumentenbasis bezeichnet. 

2. Fakten 

sind n-stellige Beziehungen zwischen Termen. Sie bilden eine einheitliche Objektklasse für 
die folgenden, häufig differenziert betrachteten Beziehungsarten: 

2.1 bibliographische , i.a. 2-stellige Beziehungen wie z.B. 'author 1 oder 'date'. 

Bsp .author( Appelrath, KOFIS) kennzeichnet einen Autor des Dokuments KOFIS. 

2.2 in Thesauri von IR-Systemen übliche, i.a. 2-stellige Beziehungen wie 'broader 1 oder 
'synonymous'. 

Bsp. Wenn 'Expertensysteme 1 und 'Wissensbasierte Systeme' als Synonyma 
verstanden werden, kann dies durch ein Fakt synonymous(Expertensysteme, 
Wissensbasierte Systeme) zum Ausdruck gebracht werden. 

2.3 die Beziehung 'relevant', die einen Dokumenti dentifikator mit einem dieses Dokument 
inhaltlich charakterisierenden Deskriptor verbindet. 

Bsp. Prolog 1 ist eines der für diesen Artikel vergebenen Schlüsselwörter und führt zur 
Beziehung relevant(Prolog, KOFIS). 

2.4 weitere (vom Benutzer frei definierbare) Beziehungen. 

Bsp. Prolog ist ein Beispiel einer deskriptiven Sprache, was durch das Fakt 
instanceof (Prolog, Deskriptive Sprachen) ausgedrückt werden kann. 

2.5 implizite Beziehungen, die über Inferenzregeln definiert sind. Die Inferenzregeln sind 
implikatorische Aussagen über nicht explizit vorhandene, i.a. strukturelle Beziehungen 
(z.B. Symmetrie oder Transitivität) von Termen, die auch zum Faktenretrieval genutzt 
werden können. 

Bsp. Die Aussage, dass ein Beispiel x einer Klasse y auch Beispiel einer Klasse z ist, 
wenn y eine Unterklasse von z ist, lässt sich durch die Regel instanceof(x, y) A isa(y, 
z) -> instanceof (x, z) formulieren. Eine geeignete Auswertung dieser Inferenzregel 
mittels eines Inferenzmechanismus 1 erlaubt damit auch die Beantwortung der Abfrage 
nach der (impliziten) Beziehung instanceof (Prolog, Sprachen). 

3. Regeln 

sind Festlegungen über die algorithmische Behandlung von Wissen, d.h. insbesondere 
Retrieval, Update und Konsistenzerhaltung von Fakten. 

3.1 Retrievalregeln beschreiben den Inferenzprozess zur Beantwortung von Abfragen nach 
Dokumenten. 

3.2 Konsistenzregelnl egen die vom Benutzer geforderte Konsistenz von Extensionen seiner 
Wissensbasis fest. 

Rollen sind Typen von Termen, wobei ein Term mehrere Rollen besitzen kann. 

Bsp. In KOFIS existieren vordefinierte Rollen für Terme wie z.B. Dokumenti dentifikator und 
Person, der Benutzer hat aber die Möglichkeit, seinen Termbestand durch selbst-definierte 
Rollen stärker zu typisieren. 
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Faktarten sind Typen von Fakten und legen durch ihre Definition z.B. die Steiligkeit der 
Beziehung, die in den einzelnen Stellen etiaubte(n) Roile(n) der Terme und evtl. administrative 
Informationen ("wer hat wann zu welchem Zweck diese Faktart definiert?") fest. 

Bsp.Die Faktart author wird etwa alt zweistellige Beziehung definiert, deren 1. Term die Rolle 
Person und deren 2. Term die Rolle Dokumentidentifikator besitzt. 

Faktenkollektionen sind - vereinfacht gesagt - Zusammenfassungen von Faktarten zu einer 
"semantischen Einheit". Dahinter steht de Absicht, Fakten (dieser ausgezeichneten Faktarten) 
zutammenzufassen, die sich durch gewisse inhaltliche Abhängigkeiten autzeichnen. Eine solche 
Sichtweise ist notwendige Voraussetzung für ein transaktions-orientiertes Update, da 
Konsistenzforderungen oft nur bei einem faktenübergreifenden Verändern von Wissen 
überprüfbar sind. 

Bsp. Fakten der Faktarten author, title und date mit gleichem Dokumentidentifikator (jeweils 2. 
Term der entsprechenden Fakten) bilden eine semantische Einheit bibliographischer 
Informationen zu einem Dokument. 

In KOFIS tauchen verschiedene, dokumentbezogene Faktenkollektionen wie z.B. book, journal 
paper, und letter auf. Zur genauen Definition dieser - und generell auch anderer - 
Faktenkollektionen gehören neben Angaben über die zu einer Einheit zusammengefassten 
Faktarten auch Informationen über evtl. Abhängigkeiten bezüglich der geforderten oder 
erlaubten Eigenschaften der jeweils zusammenfassbaren Fakten. 

Bsp. Die Definition einer Faktenkollektion journal paper könnte etwa bestehen aus 

Name:joumal paper 

Faktaxten: 1 . title (mandatory) 

2. author (mandatory, multivalued) 

3. date 

4. journal (mandatory) 

Abhängigkeit: Alle Fakten müssen den gleichen Dokumentidentifikator besitzen, 

wobei z.B. mandatory die Existenz eines entsprechenden Fakts zwingend vorschreibt (es 
darf also kein journal paper ohne Titel-, Autor- und Zeitschriftenangabe geben) und 
multivalued die Zusammenfassung mehrerer Fakten der gleichen Faktart erlaubt (es dürfen 
mehrere Autoren zu einem journal paper existieren). 

Da wir in KOFIS als Faktenkollektionen nur verschiedene "Dokumentarten 11 (book, journal 
paper, letter, usw.) betrachten, ersetzen wir den universelleren Begriff der Faktenkollektion 
durch den KOFIS-spezifischen Begriff Dokumentart . 

Somit können wir in der KOFIS- Welt folgende sieben Objektklassen identifizieren: Terme, 
Fakten, Regeln, Rollen, Faktarten, Dokumente und Dokumentarten. 

Bezüglich dieser Objektklassen soll KOFIS dem Benutzer differenzierte Retrieval- und 
Updatefunktionen anbieten, die im nachfolgenden Abschnitt skizziert werden. 




1.2 Opiraüoiüa 
Retrieval 
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KOFIS soll als persönliches Information Retrieval (IR)-System das gezielte Bereitstellen von 
Dokumenten ermöglichen. Ausgangspunkt ist dabei eine Reihe von Termen, die mit boole- 
schen Operatoren verknüpft sind. Der Prozess des Auffindens gewünschter Dokumente soll 
dabei durch die Angabe individueller Strategien definiert werden können. 

Neben diesem Aspekt des Dokumentenretrieval soll auch Wissen in Form von Termen und 
Fakten, die ebenfalls "und-" bzw. "oder-verknüpft" sein können, erfragbar sein. Schliesslich 
soll KOFIS insbesondere über Inferenzregeln ableitbare, nicht extensional gespeicherte Fakten 
ableiten und diese auch zum Retrieval verwenden können. 



Update 

KOFIS soll Updates (Einfügen, Löschen und Ändern) von Objekten aller Objektklassen der 
Wissensbasis (Terme, Rollen, Fakten, Faktarten, Regeln, Dokumente und Dokumentarten) 
unterstützen. 

Bei allen Updates sollen Konsistenzprüfungen durchgeführt und die dafür notwendigen 
Konsistenzregeln soweit wie möglich vom Benutzer selbst definiert werden. Die 
Konsistenzregeln für KOFIS sollen die Formulierung flexibler Reaktionsmechanismen bei 
Konsistenzverletzungen ermöglichen. 

Wir erwarten häufige Updates von Termen, Fakten, Regeln und Dokumenten, so dass eine 
Interaktivität der Update- Komponente unverzichtbar ist. 



Anforderungen an die Benutzerschnittstelle 

Die Objekte von KOFIS sollen in Windows (jeweils einer Objektklasse entsprechend) 
repräsentiert und die darauf definierten Operationen in Menüs angeboten werden. Jeder 
Benutzer kann KOFIS auf seinen Arbeitsstil anpassen, indem er Windows zu individuellen 
Arbeitsumgebungen zusammenfasst. 

Arbeitsumgebungen sind Kollektionen von Windows, die für eine bestimmte Arbeit benötigt 
werden, z.B. für die Dokumentenerfassung, das Retrieval von Wissen oder das Ändern von 
Regeln. 

Der Benutzer kann aus einer Menge von vorgegebenen Windows auswählen, das Layout (Lage 
und Grösse der Windows) bestimmen und eigene Namen für Objektklassen und Operationen 
vergeben. 



1.3 Modellierung 

Die sieben Objektklassen der KOFIS Wissensbasis sind im Abschnitt 1.1 umgangssprachlich 
beschrieben worden. Zur Spezifikation der Abhängigkeiten zwischen den verschiedenen 
Objektklassen wurde eine formale Beschreibung der Objektklassen und der darauf definierten 
Operationen durchgeführt ([JASP]). Für diese Modellierung benutzten wir das semantische 
Datenmodell SDM ([HAMC]) in einer in unserer Gruppe erweiterten Version ([APES]). SDM 
bietet eine Sprache für die Definition konzeptioneller Schemata für Datenbanken. Ein SDM- 
Schema besteht aus einer Menge von Klassen , die durch die Abstraktionsmechanismen 
Aggregierung, Generalisierung und Spezialisierung verbunden sein können. Eine Klasse 
beschreibt als (gedachte) Einheit eine Kollektion von anwendungsabhängig zusammenge- 
hörenden Objekten. 
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Ag gregierung definiert eine Klasse aus einer Menge von anderen Klassen. Dazu werden den 
Objekten der neu zu definierenden Klasse Attribute zugeordnet, deren Wertebereiche wiederum 
Klassen sind. Wertebereiche können auch die sogenannten "built-in- Klassen" STRING, 
NUMBER oder INTEGER sein. Ein Objekt der so definierten Klasse wird durch seine 
Attributwerte konstituiert. Aggregierung ist eine injektive Abbildung von einer Klasse in ein 
Kreuzprodukt von Klassen. 

Generalisierung legt eine Menge von Entitäten einer Klasse als ein Objekt einer neuen Klasse 
fest, ist also eine nicht-injektive Abbildung zwischen zwei Klassen. 

Spezialisierung definiert eine Klasse als Teilmenge einer bestehenden Klasse und bildet eine 
injektive, aber nicht surjektive Abbildung zwischen zwei Klassen. 

Die in SDM angebotenen Sprachkonstrukte erlauben die gemeinsame Benutzung von 
Aggregierung und entweder Generalisierung oder Spezialisierung zur Definition einer Klasse. 
Damit können die Objekte der durch Spezialisierung und Generalisierung erzeugten Klassen 
zusätzliche Attribute bekommen, die in "Abbildungsrichtung" vererbt werden. 



Konsistenzbedingungen in SDM- Schemata 

Durch jede SDM-Beschreibung werden sogenannte SDM-inhärente Konsistenzbedingungen 
festgelegt, die sich aus der Semantik der verwendeten Sprachkonstrukte ergeben. Für die 
Generalisierung gilt beispielsweise: ein Objekt einer durch Generalisierung definierten Klasse 
muss auch in der Klasse, über die generalisiert wurde, vorhanden sein. 

Ferner gibt es in der zu modellierenden Welt sogenannte schema-inhärente 
Konsistenzbedingungen, die nicht in dem benutzten Modell repräsentiert werden können und 
meist als zusätzliche Bedingungen in ein Schema aufgenommen werden. Eine solche Bedingung 
könnte etwa sein: "Die Argumente eines Fakts müssen der Stellenbeschreibung für dieses Fakt 
entsprechen". Diese Konsistenzbedingungen werden in element- und mengenbezogene 
Abhängigkeiten unterteilt, um ein auf Aktionen aufbauendes Transaktionskonzept zu realisieren. 
In [AFES] wird eine Erweiterung von SDM um Metaklassen vorgeschlagen, um einen Teil 
dieser schema-inhärenten Abhängigkeiten ebenfalls modellieren zu können. 

Neben SDM- und schema-inhärenten Konsistenzbedingungen gibt es noch 
Konsistenzbedingungen, die aus den Extensionen eines Schemas resultieren. Z.B. möchte man 
bei der Definition der broader-Beziehung deren Antisymmetrie definieren: falls ein Fakt 
"broader(x, y)" in KOFIS existiert, dann soll kein Fakt "broader(y, x)" existieren dürfen. 
Solche, vom Benutzer definierbaren Konsistenzbedingungen werden noch diskutiert. 
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2. Entwurfsentscheidungen 



2.1 Lilith workstation and Software-Portabilität 

Im Projekt war rasch die Entscheidung gefallen, für die KOFIS-Implementierung den im Institut 
entwickelten Arbeitsplatzrechner Lilith ([WIRT]) zu verwenden. Die Lilith besteht aus einer 
zentralen Recheneinheit mit einem bit-slice-Prozessor, einem Hauptspeicher mit 128 IC bzw. 
256 K "Worten" zu 16 Bit, je einem Controller für Plattenspeicher (auswechselbare Kassette mit 
10 MByte) und Bildschirm (bitmap-display basierend auf raster-scan mit 592 Zeilen und 768 
Punkten) sowie Schnittstellen für Tastatur und Zeigegerat, genannt Maus (dreiknöpfig). 

Die Sprache Modula-2 ist konsequenterweise die einzige auf der Lilith verfügbare, denn 
Ausgangspunkt war die Entwicklung einer neuen Programmiersprache (Modula-2), für die dann 
"nur" eine geeignete workstation (Lilith) gebaut wurde. Für das Projekt KOFIS bedeutete eine 
Festlegung auf Lilith also auch eine Festlegung auf Modula-2, wobei ein in Modula-2 
geschriebener Prolog-Interpreter natürlich auch die Möglichkeit zur gewünschten 
Softwareentwicklung in Prolog eröffnet. 

Wegen ihres Leistungsprofils, ihrer Zuverlässigkeit und Verfügbarkeit sowie vor allem wegen 
ihrer hervorragenden Softwareentwicklungsumgebung war die Entscheidung für die Lilith 
unbestritten, doch wurde gleichzeitig festgelegt, durch eine bei der Implementierung strikt 
einzuhaltende abstrakte Modula-2-Maschine (im Projekt als Host-Schnittstelle bezeichnet) 
Portabilität bezüglich anderer Rechner zu gewährleisten. Eine solche Portabilität war 
insbesondere wegen der Einbindung des Projekts KOFIS in externe Kooperationen unbedingt 
anzustreben. 



2.2 Benutzerschnittstelle 

Der Benutzer soll die KOFIS-Objektklassen weitgehend so dargestellt bekommen, wie sie in 
SDM modelliert sind. Dazu wurde die Benutzerschnittstelle KUser Interface definiert, die 
spezielle Fenster zur Darstellung der Objektklassen anbietet. 

Jedes Fenster besteht aus einem Formular zur formatierten und einem Freitext zur 
unformatierten Eingabe. Ein Formular besteht aus verschiedenen Slots, die jeweils ein Attribut 
einer Klasse daxstellen. 

Die individuelle Definition von Arbeitsumgebungen wird durch Erstellen eines Benutzeiprofils 
ermöglicht: der Benutzer kann Windows und Operationen auswählen und umbenennen sowie 
die Topologie der Windows auf dem Bildschirm festlegen. Nach dem Aufruf von KOFIS kann 
der Benutzer eine der definierten Arbeitsumgebungen aus wählen, diese aber über Auswahl eines 
Menü-Kommandos jederzeit wieder wechseln. 



2.3 Prolog 

Eine wichtige Entwufsentscheidung war die, Inferenzmechanismen zur Realisierung von 
Update und Retrieval einzusetzen. Weiterhin sollten sich sowohl die Retrieval- als auch die 
Updatekomponente auf die Unifikation von Variablen (Belegung mit "passenden" Termen) 
sowie auf eine Backtracking -Strategie stützen. 

Es lag daher nahe, diese Bestandteile der Sprache Prolog zu entlehnen. Zu diesem Zweck wurde 
ein am Institut in Kooperation mit dem BBC-Forschungszentrum entwickelter ProlQg- 
Tnterpreter [MULL], der eine Schnittstelle zu Modula-2 besitzt, unseren Anforderungen 
entsprechend angepasst. 
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Dazu Ist auch eine spezielle S^icherverwaltung für Tenne notwendig, welche die Rollen (der 
Terme) berücksichtigt. Schnittstellen zur Wissensbasis sowie Grundoperationen (wie z.B. 
Mengenoperationen) zur effizienten Realisierung von Produktionssystemen sind ebenfalls 
anzubieten. Diese Teile sollen in Modula-2 implementiert und über eine Schnittstelle für Prolog- 
Programme verfügbar gemacht werden. 



2.4 Retrieval 

Neben dem Retrieval der Objektklassen der Wissensbasis ist insbesondere das intelligente und 
gezielte Wiederauffinden von Dokumenten (ausgehend von einer Query) eine wichtige Fähigkeit 
von KOFIS. 

Als Queries sind Folgen von Termen mit den binären Verknüpfungen and, or und butnot 
zugelassen. Der Operator and bedeutet, dass nur solche Dokumente gesucht werden, für die die 
Retrie valbe dingung (siehe unten) für beide Terme gilt. Analoges gilt für or. Der Operator 
butnot stellt eine beschränkte Negation dar. Mit dem Ausdruck "Deskriptive Sprachen butnot 
Prolog" werden z.B. Dokumente gesucht, die durch 'Deskriptive Sprachen' beschrieben 
werden, jedoch keine Beziehung zu 'Prolog' besitzen. Queries dürfen beliebig geklammert 
werden. 

KOFIS transformiert die Query in eine disjunktive Normalform. Bei dieser Transformierung 
werden die vom Benutzer angegebenen Terme auf Übereinstimmung mit den Termen der 
Wissensbasis geprüft. Ein spezielles Ähnlichkeitsmass (siehe 3.4) erlaubt dabei die Erkennung 
typischer Schreibfehler sowie Beugungsformen von Wörtern. 

Als Modell für den Retrieval-Prozess in KOFIS wurde ein Pro duktionssys tem gewählt. 
Ausgehend von einer durch Backtracking rekursiv aufzählbaren Menge von disjunktiven 
Termen soll eine gleichfalls rekursiv aufzählbare Menge von Dokumenten produziert werden. 
Dies geschieht durch die Anwendung von speziellen Produktionsregeln r die den bereits in 
Abschnitt 1 .1 vorgestellten Retrie valiegeln entsprechen. Eine solche Retrievalegel besagt, dass 
für einen gegebenen Term der Query die Retrievalaktionen durchgeführt werden, wenn die im 
if-Teil spezifizierten Bedingungen (siehe unten) auf den aktuellen Zustand der Wissensbasis 
zutieffen. Eine Regel 

relevant: for Term if relevant(Term, Document) then retrieve Document. 

z.B. bedeutet: wenn für einen gegebenen Term eine Relevanz- Be Ziehung zwischen dem Tenn 
und einem Dokument besteht, so ist dieses in die Menge der gefundenen Dokumente 
aufzunehmen (Rettiml&tiQn)- 

Bei der Formulierung von Retrievalaktionen dürfen neben beliebigen Prolog-Prädikaten die 
Operationen retrieve, exclude, use und discard verwendet werden. Diese Operationen 
ermöglichen die Inklusion und Exklusion von Dokumenten in die Dokumentmenge bzw. 
Erweiterung (Aufnahme von Termen) und Einschränkung (Streichung von Termen) der Query. 
Die Reihenfolge der Anwendung der Retrievalregeln wird von den Ziel Vorstellungen, d.h. dem 
Informationsbedürfnis des Fragestellers, bestimmt. Dazu stehen in KOFIS Retrieval- 
Kontrollregeln (im folgenden kurz Kontrollregeln genannt) zur Verfügung. 

Bsp. (1) to_find all select Rules until false. 

(2) to_find direct select Rules until false restrict [direction = direct]. 

(3) to_find some select relevant until ndoc(N) and N=10. 

Die erste Kontrollregel besagt, dass alle Retrievalregeln analog zu Prolog, d.h in der 
Reihenfolge der Aufschreibung nach Backtracking- Strategie, angewendet werden. Dies erfolgt 
solange, bis keine Retrievalbedingung mehr auf die Wissensbasis zutrifft (until false). Regel 
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(2) bedeutet eine Einschränkung der anwendbaren Retrie valregeln auf solche, die mit der 
Richtung "direct" venehen wurden. 

In der aktuellen KOFIS-Version ist als Regelauswahl entweder "alle" (angezeigt durch eine 
Variable) oder "bestimmte" (ein konkreter Retrie valname) zugelassen. Im Beispiel (3) ist dies 
die Retrievalregel mit Namen "relevant" . 

Als Abbruchbedingung (until) sind beliebige Prolog- Bedingungen möglich. Restriktionen 
werden durch Vergleiche sowie die Operatoren min und max für die Auswahl minimaler bzw. 
maximaler Attribute ausgedrückt. 

Um eine Dokumentenrecherche mit KOFIS durchzuführen, wird nach Eingabe der Query ein 
Ziel mit dem Ausdruck "find <Ziel>" bestimmt. So führt die Eingabe: 

query ('Expertensysteme 1 and 'Information Retrieval') or 'KOFIS', 
find some. 

zu einer Dokumentenrecherche nach Zitaten, die relevant bezüglich 'Expertensysteme' und 
'Information Retrieval' als auch relevant bezüglich 'KOFIS' sind. Dabei spezifiziert die 
Zielvorstellung "some" (siehe Kontrollregel (3)) die K ontro 11s träte gie . D.h., dass nur die 
Retrievalregel mit Namen "relevant" angewendet wird, bis entweder keine Regel mehr 
anwendbar ist oder die Anzahl der gefundenen Dokumente 10 beträgt. 



2.5 Update und Konsistenzprüfung 

Bei jedem Update sollen verschiedene Konsistenzprüfungen durchgeführt werden. Die 
zugrundeliegende Verwaltung der Wissensbasis kennt das Schema, das alle zulässigen Objekte 
beschreibt, und lässt nur Updates zu, die mit dem Schema konsistent sind, d. h. sie garantiert 
die schema-inhärente Konsistenz. Diese Prüfungen sind fest in das System "einzubauen". 

Der Benutzer kann darüber hinaus zusätzliche Konsistenzregeln in Form von Tri ggern 
definieren, die von der Update- Komponente ausgewertet werden. Ausserdem ermöglicht es die 
Up date- Komponente, auf die Verletzung von Konsistenzregeln flexibler zu reagieren als die 
Wissensbasis-Verwaltung, indem bei Konsistenzverletzungen automatische An passungen 
versucht werden, um die Konsistenz wieder zu erreichen. 



Trigger 

Zur Formulierung benutzerdefinierter Konsistenzregeln haben wir Trigger (Test- Aktions-Paare) 
gewählt. Sie erlauben dem Benutzer die Definition flexibler Reaktionen bei 
Konsistenzverietzungen und wesentlich effizientere Konsistenzprüfungen als bei einer rein 
deskriptiven Formulierung von Konsistenzregeln ([APES]). 



Die Syntax der Trigger lautet 

TRIGGER <name> 

ON <update> 

IF <con<fition> 

THEN <action> 



/* (eindeutiger) Name */ 

/* Update- Bedingung */ 

/* Wissensbasis- Bedingung */ 

/* Aktion */ 



Für jedes Update werden alle Trigger getestet. Falls Update-Bedingung und Wissensbasis- 
Bedingung erfüllt sind, wird die zugehörige Aktion ausgeführt. 
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Die Bedingungen an die Witsentbaaie sind Konjunktionen von Formeln, wobei eine Formel 
wiederum aus disjunktiv verknüpften Teilformeln bestehen kann; die Aktionen sind 
Konjunktionen von Operationen. Als Operationen in einer Aktion sind Fragen und Meldungen 
an den Benutzer sowie Folgs-Updates der Wissensbasis zugelassen. 

Es werden vier verschiedene Reaktionsweisen bei Konsistenzverletzungen unterschieden: 

- Ablehnung des Updates 

- Ausführung des Updates und Information des Benutzers 

- Ausführung des Updates und Frage nach weiteten Updates 

- Ausführung des Updates und Ausführung von (systeminitiierten) Folge-Updates . 

Bsp. TRIOOER antisymmetric 

ON INSERTION broader(X,Y) 

IFbroader(Y,X) 

THEN REJECT /* Ablehnung des Updates */ 

TRIOOER fortsetzung-relevant 

ON INSERTION relevant(X ,Y) 

IF synonymous(Z,X) OR synonymous(X ,Z) 

THEN INSERT relevant(Z, Y) /* Ausführung von Folge-Updates */ 



Anpassungen 

Die Wissensbasis- Verwaltung erlaubt nur Updates, die die schema-inhärenten 
Konsistenzbedingungen einhalten. Ein KOFIS-Benutzer möchte aber manchmal Updates 
trotzdem durchführen. 

Z.B. möchte er ein neues Fakt "likes(a,b)" einfügen für das noch keine Faktart definiert ist und 
wo eine vollständige Definition der Faktart noch nicht möglich ist. Es kann nun eine sogenannte 
"Dummy -Faktart von der Update-Komponente eingefügt werden, die nur den Namen "likes" 
und die Stelligkeit 2 festhält. Nach dieser Anpassung ist das ursprüngliche Update konsistent 
ausführbar. 

Die Update-Komponente beinhaltet eine Menge von Regeln, um solche automatischen 
Anpassungen zu versuchen. 

Transaktionen 

Ein Update mit allen Konsistenztests, evtl. Anpassungen und Folge-Updates wird als 
Transaktion behandelt (Menge von Operationen, von denen entweder alle oder keine ausgeführt 
wird). 

Zuerst wird das Update in der Wissensbasis versucht. Falls es schema-inhärente 
Konsistenzbedingungen verletzt, versucht die Update- Komponente nach automatischen 
Anpassungen das Update noch einmal. 

Wenn das Update auch jetzt inkonsistent bleibt, wird es endgültig abgelehnt. 

Im erfolgreichen Fall wertet die Update-Komponente noch die Trigger aus und führt das Update 
durch, wenn mit keinem Trigger die Inkonsistenz gezeigt werden kann. 

Wir verfolgen bei den Transaktionen den optimistischen Ansatz , d. h. wir erwarten dass die 
meisten Updates konsistent sind, führen sie deshalb sofort aus und machen sie rückgängig, 
wenn später eine Inkonsistenz gefunden wird. 




2.6 Verwaltung der Wissensbasis 



Abschätzungen bezüglich des KOFIS-Mengengerüsts eigaben, dass die Daten (insbesondere die 
Fakten als mengenmässig deutlich grösster Teil) nicht im Hauptspeicher der Lilith workstation 
Platz finden würden. Aus diesem Grund wurden Überlegungen zur externen Speicherung der 
Daten durch ein geeignetes Datenverwaltungssystem notwendig. 



Grundsätzlich e Entwurfsentscheidungen für die Verwaltung der Wissensbasis: 

- Alle Objekte müssen vom Prolog-Interpreter aus zugreifbar sein. 

- Fakten müssen bzgl. aller Argumente zugreifbar sein. 

- Faktarten müssen mindestens bzgl. Name und Stelligkeit zugreifbar sein. 

- Regeln werden hauptspeicherresident gehalten und sind von Prolog direkt zugreifbar. 

Resultierende Anforderungen an eine externe Datenverwaltung der Wissensbasis: 

- Möglichst vollständige Invertierung der Faktendatei, um partial-match queries (nicht 
argument-vollständig spezifierte Abfragen) bzgl. aller Argumente durchführen zu können. 

- Die externe Datenverwaltung hat eine Ein-Tupel-Schnittstelle . da Prolog "one tuple at a time" 
fordert, d.h. der Prolog-Interpreter benötigt und verarbeitet die Tupel einzeln nacheinander. 

- Die Schnittstelle zur externen Datenverwaltung ist über built-in-Prädikate in Prolog definiert. 



Konzepte einer DB- Unterstützung für Prolog, wie sie in [APPE] ausführlich beschrieben 
werden, waren wegen der 1. Forderung nicht ausreichend. Wir entschieden uns für das im 
Institut entwickelte Datenverwaltungssystem GridFile ([NIEV]), da es folgende Vorteile bietet: 

- Es erlaubt Abfragen mit mehreren gleichberechtigten Schlüsseln auf Tupel, die variable 
Nicht-Schlüssel-Informationen haben können. Dabei ist die vollständige Invertierung bis 
zu der maximal möglichen Anzahl von Schlüsseln garantiert. 

- Prolog-Unifikation eines Prädikats kann einfach auf die vom GridFile angebotenen 
partial-match queries abgebildet werden. 

- Das GridFile besitzt eine Ein-Tupel-Schnittstelle, d.h. es müssen keine mengenwertigen 
Antworten, wie sie eine relationale Datenbank liefert, zwischengespeichert werden. 

- Es wird die Möglichkeit zur Bearbeitung von multiple queries (das sind Queries mit 
mehreren "gleichzeitig bekannten" Teil-Queries) angeboten. Damit kann das Backtracking 
eines Prolog- Interpreters unterstützt werden, ohne die Resultate mehrerer zu einem 
Zeitpunkt bekannter Queries speichern zu müssen. 

Die externe Datenverwaltung garantiert die Einhaltung der SDM-inhärenten sowie der 
elementbezogenen schema-inhärenten Konsistenzbedingungen. Bei Verletzung von 
Bedingungen wird die erste verletzte Konsistenzbedingung als Fehler an die aufrufende 
Komponente zurückgemeldet. 

Um das Backtracking von Prolog zu unterstützen, wird für die Prädikate, auf denen ein 
Backtracking durchgeführt werden darf (das sind die Retrieval-Prädikate), ein zusätzlicher 
Verwaltungsaufwand notwendig (insbesondere ist ein Query-manager zur Verwaltung der 
multiple queries zu integrieren). 

Zur administrativen Unterstützung der Wissensbasis werden den Fakten und Faktarten die 
Verwaltungdaten Autor, Zweck und Eintragsdatum zugeordnet. Über diese Verwaltungdaten 
kann ebenfalls auf die Objekte zugegriffen werden. 
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3. Aut gewählte Implementierungsaspekte 
3.1 Softwarearchitektur 
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Abb. 2 KOFIS- Architektur 



Abb. 2 gibt einen Überblick über die Architektur von KOFIS. Das System lässt sich auf der 
obersten Ebene in die Komponenten Userinterface (Kommunikation mit dem Benutzer), 
InferenceEngine (Retrieval und Update auf Grundlage eines Prolog- Interpreters) und 
Knowledge Base (Speichersystem für alle KOFIS-Objekte) aufteilen. 
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Bern. Im folgenden wollen wir die hierarchische Einordnung einer Komponente dadurch zum 
Ausdruck bringen, dass wir ihrer Bezeichnung jeweils die Anfangsbuchstaben der 
hierarchisch darüber liegenden Komponenten voranstellen (z.B. zeigt KUserlnterface die 
Einbindung von Userinterface in KOFIS und KIProlog die Einbindung von Prolog in die 
Inference Engine von KOFIS). 

KUserlnterface stellt Windows bereit, die die KOFIS-Objekte visualisieren, und lässt 
Operationen auf diesen Objekten durch die Auswahl von Menü-Kommandos zu. 

Die Teilkomponente WoriangEnvironmentHandler erlaubt die Zusammenfassung von Fenstern 
zu Arbeitsumgebungen. Eine solche Arbeitsumgebung modelliert eine typische Bürotätigkeit, 
etwa die Aufnahme von Dokumenten oder auch die Recherche in der Wissensbasis. 

KInferenceEngine enthält die Teilkomponenten KlUpdate (mit Konsistenzprüfung) und 
KIRetrieval (mit Navigationsmöglichkeiten in der Wissensbasis). Diese Komponenten stützen 
sich alle auf die Unifikations- bzw. Backtracking-Fähigkeiten des zugrundeliegenden Prolog- 
Interpreters (KIProlog). 

KKnowiedgeBase schliesslich bietet eine Menge in Modula-2 realisierter Prolog-Prädikate zur 
Verwaltung der Objekte der sieben KOFIS-Objektklassen an. Die schema-inhärente Konsistenz 
wird von der Teilkomponente Consistency garantiert. Ein "Query Manager" verwaltet die 
verschiedenen zu einem Zeitpunkt abzuarbeitenden Anfragen an die Wissensbasis. Das GridFile 
wird zur externen Speicherung der Daten benutzt. 



Hott- Schnittstelle 

Die gesamte KOFIS- Software besitzt eine einheitliche Schnittstelle zu allen 
maschinenabhängigen Implementierungsdetails (abstrakte Modula-2- Maschine Host ). Darunter 
fallen unter anderem I/O, Filehandling, Commandline- Interface Konvertierungen und die 
Display- Software. Diese Host-Schnittstelle wurde für verschiedene Projekte unserer 
Arbeitsgruppe eingesetzt und hat sich insbesondere durch eine gute Modulstruktur sowie ihre 
leichte Portierbarkeit ausgezeichnet. Eine Portierung auf den Apple Macintosh erfolgte z.B. in 
ca. 200 Arbeitsstunden. 

Eine wichtige Eigenschaft der Schnittstelle ist insbesondere die Einbeziehung von Fenstern, 
Menüs und Maus. Diese ist so gestaltet, dass die auf der Schnittstelle aufbauende Software, 
auch auf Computern ohne bitmap-display bzw. Hardware-Zeigegeräten wie einer Maus läuft. 



3.2 Die Komponente KUserlnterface 

Bitmap- display, Maus und Menüs ermöglichen eine angemessene Realisierung der 
Arbeitsumgebungen. In Abb. 3 wird ein Ausschnitt aus der Arbeitsumgebung 
Dokumenterfassung mit Windows für Dokumente und Fakten gezeigt. Beide sind zum 
Zeitpunkt des "Schnappschusses" zum Teil gefüllt. Im Dokumenten-Window fehlt noch der 
Dokumentidentifikator (DID), Bemerkungen (REMARK) sind optional. Im Fakten-Window 
können Mengen von Fakten manipuliert werden. 
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Abb. 3 Ausschnitt aus der Arbeitsumgebung Dokumenterfassung 

Wenn der Benutzer die Erfassung beenden will, kann er mithilfe der MenUs die Befehle zum 
Einfügen der neuen Objekte geben. Erst dann werden die Benutzereingaben auf Konsistenz 
geprüft und in die Wissensbasis übernommen. So wird der Benutzer in seinem Arbeitsablauf 
nicht unnötig eingeschränkt. 



3.3 Die Komponente K Inference Engine 

Kern dieser Komponente ist ein Prologe Interpreter (KIProlog), der von den in Modula-2 
realisierten Programmteilen auf gerufen und seinerseits in Modula-2 abgefasste Prolog-Prädikate 
auswerten kann . Die Programme dieser Komponente enthalten daher sowohl in Prolog 
(Inferenzl wie auch in Modula-2 (prozedurale Elemente) codierte Teile. 
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Retrieval 

Die Komponente KIRetrieval kann alt ein Produktionssystem mit den Hauptbestandteilen 
Memoiy und Interpreter aufgefasst werden. Die Normalform der Query wird in das Working 
Memory geladen und das Production Memoiy wird mit den durch die Zielangabe spezifizierten 
Retrieval- bzw. Kontrollregeln gefüllt. Der Interpreter wühlt dann in einem recognize-and-act 
Zyklus die durch die Kontiollstrategie spezifizierte Regel aus. Ist keine spezielle Strategie 
definiert, so erfolgt die Auswahl in der in Prolog^Interpretem üblichen Reihenfolge. 

Wenn eine Regel gewählt wurde, so wird ihre Anwendbarkeit auf die Wissensbasis geprüft. 
Dabei können freie Variable mit entsprechenden Query-Termen besetzt werden. Fällt diese 
Prüfung positiv aus, so werden die spezifizierten Retrievalaktionen durchgeführt. Dies kann 
einerseits eine Veränderung der Query bedeuten, anderseits aber auch Änderungen in der Menge 
der gefundenen Dokumente bzw. im Memory bewiiken. 

Nach der Ausführung jeder Regel wird eine eventuell vorhandene Abbruchbedingung (until) 
geprüft. Trifft diese zu, so hält der Interpreter. Andernfalls erfolgt Backtracking sowohl über 
die Retrievalregeln bzw. die Kontrollregeln wie auch über die Menge der Query-Terme 
(Aufzählung). 

Die Menge der Query-Terme kann bei der Abarbeitung einer Query wachsen und/oder kleiner 
werden. Der Backtracking-Mechanismus ist so realisiert, dass jeder Query-Term höchstens 
einmal zur Beantwortung der Query herangezogen wird. Dies garantiert die Terminierung des 
Suchprozesses. 



Update 

Bei jedem Update der KOFIS-Wissensbasis müssen die relevanten Konsistenzregeln getestet 
werden. Die Update-Komponente benötigt also einen Mechanismus um das Zusammenspiel der 
Regeln zu kontrollieren. Prolog bietet dazu Backtracking als "eingebaute Kontiollstrategie" an. 
Ausserdem müssen die Bedingungen der Konsistenzregeln auf der Wissensbasis getestet und 
mit Werten belegt werden. Auch dazu bietet Prolog mit der Unifikation eine Methode an. 

Aus diesen Gründen wurde die Update- Komponente in Prolog implementiert. Einen guten 
Einblick in die algorithmische Lösung von KlUpdate gibt [APES]. 



3.4 Die Komponente K Knowledge Base 

Die Verwaltung der Wissensbasis ist in Komponenten zur Konsistenzerhaltung, zur Query- 
Verwaltung und zur Objekte/Objektklassen-Verwaltung unterteilt. Zuerst wird die Verwaltung 
der Terme und die Realisierung eines Ähnlichkeitsmasses, dann als ein Beispiel die Realisierung 
der Speicherung der Fakten beschrieben. Die Update- und Retrievalregeln werden in einer 
separaten hauptspeicherresidenten Struktur (Prolog) verwaltet. 



Termverwaltung/ Ähnlichkei Umass 

Durch eine Normierung von Benutzereingaben werden vom Benutzer eingegebene Terme mit 
den in der Wissensbasis vorhandenen Termen verglichen. Terme sollen dabei als semantisch 
gleich erkannt werden, wenn sie sich nur durch eine fehlerhafte Schreibweise (Tippfehler) oder 
durch Kasus bzw. Numerus unterscheiden. 
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Ein spezielles AKnlinh^itema— vergleicht die in den Wörtern verkommenden Folgen jeweils 
zweier benachbarter Buchttaben (IM gramme) . Dabei werden die Digramm-Häufigkeiten der 
deutschen und englischen Sprache berücksichtigt. Das Verfahren garantiert eine sichere 
Erkennung der vier am häufigsten auftretenden Tippfehlerklassen und untencheidet nicht- 
ähnliche Worte mit guter Trennschärfe. 



Zugriff auf externe Daten/ Faktenverwaltung im OridFile 

Die externe Datenverwaltung ist in Modula-2 realisiert und bietet eine deklarative Schnittstelle 
(wie die Komponente ebenfalls KKnowledgebase genannt) an. Diese Schnittstelle definiert die 
built-in-Prädikato , mit denen von Prolog aus Daten verwaltet werden. Die zur Realisierung der 
built-in-Prädikate benötigten Operationen (Prozeduren) werden aus den Teilkomponenten der 
KKnowledgebase importiert. 

KKnowledgebase besteht aus den Teilkomponenten KKconsistency, KKquerymanger, den 
Moduln zur Verwaltung der Objekte/Obi ektklassen KKroles , KKfacts, KKfacttypes , 
KK documents, KKdocumenttypes und KKinferencerules , sowie einigen Hilfsmoduln. Diese 
Komponenten bauen ihrerseits auf der abstrakten Modula-2-Maschine HOST, dem Modul 
KKterms (s.o.) und dem öridfile auf. Sie definieren in ihrer Gesamtheit die Prozeduren zur 
Verwaltung der Wissensbasis. Diese Prozeduren werden in der Komponente KKnowledgebase 
in die built-in-Prädikate der deklarativen Schnittstelle umgesetzt. 

KKquerymanger verwaltet alle Anfragen (Queries), die an die Moduln zur Verwaltung der 
Objekte/Objektklassen gestellt werden. Für jede Query existiert ein eindeutiger Query- 
Deskriptor, der diese Query beschreibt und auf das nächste zu liefernde Objekt verweist. Die 
Query- Deskriptoren sind mich aussen (KKnowledgebase) nicht sichtbar und werden dort mittels 
eindeutiger Query- Namen zu den entsprechenden Retrieval-Operationen spezifiziert. 

Die Fakten werden in einem GridFile gespeichert, wobei sowohl der Faktname als auch die 
Argumente des Fakts Schlüssel des GridFiles bilden müssen, um die vollständige Invertierung 
der Fakten zu garantieren. Da die Anzahl der Schlüssel eines GridFiles bei dessen Definition 
festgelegt werden muss, werden Fakten mit einer höheren als der bei der Definition maximal 
vorgesehenen Stelligkeit auf mehrere Tupel aufgeteilt. Zur Verwaltung der in mehrere Tupel 
aufgeteilten Fakten werden zwei zusätzliche Schlüssel für jeden GridFile-Eintrag definiert: ein 
eindeutiger Identifikator für jedes Fakt und die Reihenfolge , in der die Tupel ein Fakt bilden. 

Es lassen sich so Fakten mit beliebiger Stelligkeit speichern, jedoch sind zur Definition eines 
eindeutigen Identifikators für jedes Fakt und für den evtl, mehrfachen Zugriff auf das GridFile 
(um ein Fakt zu lesen oder zu schreiben) zusätzliche Kosten bzgl. Speicherplatz und Laufzeit zu 
zahlen, da auf jedes der Tupel, die ein Fakt bilden, zugegriffen werden muss. Da die meisten 
Fakten in KOFIS voraussichtlich 2-stellig sind, werden alle Fakten in einem 5- dimensionalen 
GridFile gespeichert. Der Identifikator, die Reihenfolge, der Faktname und die Argumente 
bilden die Schlüssel des GridFiles, so dass zweistellige Fakten in einem GridFile-Eintrag 
gespeichert sind. 



3.5 Quantitative Aussagen 

Die Beschreibung des Systems KOFIS soll an dieser Stelle durch einige - wenn auch vorläufige 
- quantitative Aussagen ergänzt werden. 




Programmgröss cn 



Im derzeitigen Entwicklungsstadium von KOFIS umfasst KIRetrieval ca. 2.000 Prolog- und ca. 
4.000 Modula-2-Zeilen Programm. KlUpdate ist bisher rein in Prolog realisiert (ca. 1.000 
Zeilen). 

Die Komponente KKnowledgeBase (ohne OridFile) besteht aus ungefähr 6.000 Modula-2- 
Zeilen, die Benutzerschnittstelle KUserlnterface aus ca. 4.000 Zeilen Modula-2. 



Tests und Laufzeiten 

Auf der Lilith, unserer Softwareentwicklungsmaschine, ist wegen des beschränkten 
Hauptspeichers keine Integration der KOFIS- Komponenten möglich. Man kann entweder die 
Retriewl- oder die Update-Komponente wahlweise mit KUserlnterface oder dem GridFile 
kombinieren und muss auch dann noch Beschränkungen bezüglich der Testdatenmenge 
einhalten. 

Entsprechend konzipierte Schnittstellen von KIRetrieval und KlUpdate - nach "oben" zu 
KUserlnterface und nach "unten 11 zu KKnowledgeBase - erlauben ohne grossen Aufwand ein 
flexibles Konfigurieren von KOFIS-Komponenten und damit ein alternatives Testen mit einer 
komfortableren Benutzerschnittstelle (bei kleinen, auf den Hauptspeicher beschränkten Daten) 
oder mit grösseren, im GridFile verwalteten Datenmengen (bei einer recht einfach gehaltenen 
Benutzerschnittstelle) . 

Auch die auf Macintosh portierte KOFIS-Software besitzt diesen Mangel, so dass erst die in 
Angriff genommene Übertragung von KOFIS auf eine sun-3 workstation hier eine 
Verbesserung verspricht. 

Es existiert eine Dokumenten- und Wissensbasis , die sich vor allem auf den Jahrgang 1985 der 
communications of the acm stützt. Neben einem grossen Ausschnitt des acm computing review 
classification tree, der als Thesaurus genutzt wird, sind zu ca. 80 Artikeln des Jahrgangs 1985 
ca. 1500 Fakten mit 12 Faktarten erfasst. 

Es sind einige Retrieval- und Konsistenzregeln in einem Grundstock fest definiert worden. Mit 
jeweils kleinen Änderungen dieses Bestands führen wir Tests durch, wobei fundierte Aussagen 
über Retrieval- und Updatezeiten noch nicht möglich sind. 



3.6. Ausblick 

In dieser Arbeit haben wir uns auf den Aspekt beschränkt, KOFIS als ein 
anwetidnngshe7ogenes Expertensvstem darzustellen, und die dadurch initiierte und angestrebte 
Realisierung eines anwendungsunabhängigen Prolo g- W erkzeugkas tens zur Erstellung einer 
Klasse von Expertensystemen nur am Rande erwähnt. D.h., die im Projekt entwickelten 
Werkzeuge sind so weitgehend anwendungsneutral, dass sie nach Trennung von der KOFIS- 
spezifischen Wissensbasis auch für andere - als die für KOFIS gewählte - Applikationen 
verwendet werden können. Überdies sichert die Host- Schnittstelle die gewünschte Portabilität 
der auf der Lilith entwickelten Software auf leistungsstärkere Rechner. 

Diese beiden Punkte - Werkzengcharakter und Portabilität - sind wichtige Voraussetzungen für 
die bisherigen und im Rahmen eines gerade anlaufenden EUREKA-Projekts intensivierten 
externen Kooperationen mit in- und ausländischen Partnern. 
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Programming-by-Example in einer interaktiven, 
formularorientierten Umgebung 

Michael Spenke und Christian Beilken 
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St. Augustin 



Zusammenfassung: Es wird gezeigt, wie sich ein programmierunkundiger 
Benutzer auf einfache Weise neue Werkzeuge für seinen eigenen Problembereich 
schaffen kann, indem er an einem geeigneten Beispiel demonstriert, wie er unter 
Verwendung bestehender Werkzeuge sein Problem löst. Alle Werkzeuge werden über 
eine einheitliche Formular-Schnittstelle aufgerufen. Der Evaluierungsmechanismus 
für Formulare basiert auf Constraints, die angeben, wann ein Formular korrekt 
ausgefüllt ist. Aus dem demonstrierten Beispiel wird automatisch ein Constraint-Netz 
abgeleitet, das zusammen mit einer geeigneten Auswertungsstrategie die Semantik 
des neuen Werkzeugs beschreibt. 



1. Einleitung 

Komfortable Benutzerschnittstellen, die regen Gebrauch von Menüs, Zeige- 
instrument (Maus), Icons, Fenstertechniken und hochauflösenden Graphikbild- 
schirmen machen, haben die Benutzung von Anwendungsprogrammen enorm 
erleichtert. Für den Endbenutzer ist es wesentlich attraktiver, Objekte auf dem 
Bildschrim direkt mit der Maus zu manipulieren, als in einer formalen 
Kommandosprache Befehle zu erteilen und deren Wirkung anschließend durch 
weitere Kommandos in Erfahrung zu bringen [Shn83]. 

Allerdings sind diese modernen Interaktionstechniken heute noch 
weitgehend auf die Bedienung vorgefertigter Anwendungsprogramme beschränkt. Will 
der Benutzer eigene Anwendungen programmieren, so muß er meist auf die Ebene 
der zugrundeliegenden Implementierungssprache herabsteigen. Selbst Aktionsfolgen, 
die an der Benutzeroberfläche mit Maus und Menüs ausgeführt werden können, 
müssen in einer völlig neuen Syntax formuliert werden, wenn sie Teil eines 
Programms werden sollen. Daher stellt für viele Benutzer der Übergang von 
vorgefertigten Anwendungen zur Programmierung eigener spezieller Lösungen eine 
unüberwindbare Hürde dar, obwohl der Bedarf durchaus vorhanden ist [RoF83] und 
kaum Hoffnung besteht, daß er durch professionelle Programmierer abgedeckt 
werden kann [Shu85]. Der Erfolg von Spreadsheets - trotz ihrer eingeschränkten 
Programmiermöglichkeiten - unterstreicht in eindrucksvoller Weise den Wunsch der 
Endbenutzer, eigene Anwendungen selbst mit einem universellen Hilfsmittel 
programmieren zu können. 
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Ein System, das dem Endbenutzer erlaubt, eigene Anwendungen zu 
programmieren, sollte folgende Anforderungen erfüllen: 

• Zunächst sollte bereits ein gewisser Grundvorrat von allgemeinen, einfach 
zu benutzenden Werkzeugen zur Verfügung stehen, da der Endbenutzer in 
jedem Fall überfordert ist, wenn er sich nicht auf die Probleme seines 
ureigenen Anwendungsbereiches beschränken kann. 

• Der Werkzeugbestand sollte auf einfache Weise erweitert werden können, 
indem bestehende Werkzeuge kombiniert werden. 

• Zum Programmieren sollte nicht der Übergang zu einer formalen Sprache 
erforderlich sein, sondern genau wie bei der Benutzung der Werkzeuge 
sollten im wesentlichen Gestiken mit der Maus genügen. 

• Die Analyse bestehender Programme sollte allein aufgrund der 
Beobachtung des Programmablaufes möglich sein. Eine statische 
Programmbeschreibung in einer formalen Syntax sollte auch hier 
überflüssig sein. 

• Auch unvollständige Programme sollten lauffähig sein. Einzelne 
Programmteile sollten isoliert getestet werden können und bereits 
Teilergebnisse liefern (inkrementeile Programmierung, rapid-prototyping). 

• Auch beim Programmieren sollte der Benutzer immer sofort die Wirkung 
seiner Handlung auf dem Bildschirm sehen. Er sollte nicht - wie bei der 
klassischen Form der Programmierung - gezwungen sein, sich die Wirkung 
seiner Befehle vorzustellen und sie erst später (z.B. nach dem 
Compilieren) zu überprüfen. 

Im Rahmen des Verbundprojektes WISDOM wurde das hier beschriebene 
System PERPLEX (Programming EnviRonment for Predicate-Learning from EXamples) 
konzipiert und prototypisch auf einer Symbolics-Lispmaschine implementiert. Der 
Thematik des Projektes entsprechend ist der Endbenutzer, an den hier gedacht wird, 
ein Bürosachbearbeiter, der im Rahmen von sog. Vorgängen [Krei84] [KrW86] ihm 
zugesandte Formulare aufgrund seiner lokalen Datenbestände und seines 
Verarbeitungswissens ausfüllt. Als Hilfsmittel steht ihm ein weites Spektrum von 
Basis-Werkzeugen zur Verfügung, die über eine einheitliche Formular-Schnittstelle 
aufgerufen werden. 

Der Evaluierungsmechanismus für Formulare basiert auf Constraints, die 
angeben, wann ein Formular korrekt ausgefüllt ist. Mehrere Formulare mit 
gemeinsamen Variablen bilden ein Constraint- Netz. Neue, mächtigere Werkzeuge 
definiert man, indem man an Beispielen demonstriert, wie man unter Verwendung 
bestehender Werkzeuge ein Problem löst. Aus den Beispielen wird ein Constraint-Netz 
abgeleitet, das die Semantik des neuen Werkzeuges beschreibt. 
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Das PERPLEX-System basiert auf Ideen, die zum Teil auch in anderen 
Arbeiten beschrieben werden. Vor allem die Formulierung von Datenbankanfragen ist 
auf die Arbeiten von Zloof [Zloof82, Zloof8l, Zloof77, Zloof77a] zurückzuführen. 
Constraint-Netze wurden bereits von Borning [Bor8l] sowie Sussman und Steele 
[SuS80] behandelt. Es besteht auch eine Analogie zwischen den formularorientierten 
Werkzeugen und Prolog-Prädikaten. Überlegungen zu Programming- by- Example 
finden sich unter anderem bei Bauer [Bauer79], Attardi und Simi [AS82]. Das 
Tinker-System von Liebermann /Hewitt [LH80], das Lisp-Programme aus Beispielen 
ableitet, kommt unserer Auffassung des Begriffs Programming -by- Example am 
nächsten. 

Die neueren, eher deklarativen Programmiertechniken (logisches 
Programmieren, Programmieren mit Constraints oder Gleichungen) führen zu 
mächtigeren, flexibleren Programmen als die klassische prozedurale Vorgehensweise, 
insbesondere kann die Input-Output-Richtung offengehalten werden. Andererseits 
scheint uns für den nicht mathematisch vorgebildeten Benutzer das prozedurale, 
schrittweise Vorgehen einleuchtender und weniger abstrakt zu sein. Daher wurden 
im PERPLEX-System beide Ansätze kombiniert: Der Benutzer gibt seine Beispiele 
prozedural vor, das System leitet aber eine nicht-prozedurale Darstellung daraus ab. 

Im nächsten Kapitel wird die reine Benutzung bestehender Werkzeuge 
beschrieben, während im dritten Kapitel die Konstruktion neuer Werkzeuge 
diskutiert wird. Im letzten Kapitel wird schließlich auf die Einbettung von PERPLEX in 
das Bürovorgangssystem DOMINO eingegangen. 

2. Benutzung der bestehenden, formularorientierten Werkzeuge 

Das PERPLEX-System stellt dem Endbenutzer von vorneherein eine Reihe 
von Basis-Werkzeugen zur Verfügung, die bereits ein weites Spektrum von 
Hilfsmitteln abdecken, so z.B. Taschenrechnerfunktionen, einfache Prädikate, 
relationale Datenbanken, Ein- /Ausgabe und vieles mehr. Alle Werkzeuge haben eine 

einheitliche formularorientierte Benutzerschnittstelle. 
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Der graue Hintergrund stellt die (zunächst leere) Arbeitsfläche dar. Die 
Werkzeuge werden in einem Menü angeboten (siehe Bild). Aus diesem Menü kann man 
mit der Maus ein Werkzeug auswählen, und erhält ein Formular, das - ebenfalls mit 
der Maus - an eine beliebige Stelle auf dem Bildschirm plaziert werden kann. Im 
ersten Bild sind bereits einige Formulare angezeigt. Die Formulare tragen den Namen 
des Werkzeugs, das sie repräsentieren und bestehen aus einer linearen Folge von 
Feldern, die Ein- und Ausgabe-Parametern entsprechen. Die Felder bestehen aus 
einem festen Feldnamen und einem editierbaren Feldinhalt. Zur Benutzung eines 
Formulars trägt man in einige Felder Konstanten ein und klickt dann das "Eval"- 
Kästchen in der unteren Zeile an. Tragen wir z.B. in das Formular "Plus" aus dem 
ersten Bild unter "First Term" eine 5 und unter "Second Term" eine 7 ein und klicken 
"Eval" an, dann erscheint hinter "Sum" die Summe 12: 



Plus 




Plus 


First Fern i 5 




First Tern: 5 


Second Tern : 7 




Second Term ? 


Sun: SUM 




St/flr 12 


Eval E Move □ Reshape □ Delete Q 




Eual ü Move Dj Reshape [] Delete Q 
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Viele Werkzeuge lassen sich auch rückwärts verwenden, indem andere 
Felder mit Variablen belegt werden: 




Sind alle Felder von "Plus" mit Konstanten ausgefüllt, wird überprüft, ob 
die Zahlen eine korrekte Addition darstellen. Das Ergebnis ("True" oder "False") wird 
dann in einem speziellen Fenster, dem Result- Fenster angezeigt: 



Ipiüi ! 




Results 












false 








|l 1 1 !■ —Ill 111 ■■M 1 1 III M MmmiM 







Das aktuelle Datum kann man mit einem anderen Werkzeug, nämlich 
"Current Date and Time", berechnen. Hier brauchen keine (Eingangs-)Felder 
ausgefüllt zu werden, das Datum und die aktuelle Uhrzeit erscheinen nach dem 
Evaluieren im Formular, wie im ersten Bild zu sehen. 

Neben weiteren einfachen Werkzeugen, z.B. zur Listenverarbeitung, 
wurden auch relationale Datenbanken im PERPLEX-System integriert. Als 
Demonstrationsbeispiel verwenden wir im folgenden eine kleine, aus der Literatur 
bekannte Datenbank [Zloof77], in der Informationen über Angestellte einer Firma 
(Name, Gehalt, Vorgesetzter und Abteilung) gespeichert sind. Am Beispiel dieser 
Datenbank zeigen wir zunächst, was in die Felder eines Formulars eingetragen 
werden kann. Läßt man in allen Feldern Variablen (Identifier) stehen, so werden für 
alle Variablen alle möglichen Belegungen gesucht. Bei einer Datenbank wird also ihr 
ganzer Inhalt in Tabellenform im Result-Fenster ausgegeben: 



Employees 

fi&ne ; NAME 

SALARY 

taQtr : MANAGER 
D*p*r£nen£: DEPARTMENT 

Results: (( p jones' 8000 "snUh“ “hauseh 
Unique i Yes Wo 

node : retrieve assert delete 
f valuation; Positive Negated 
Evfll H Moue Q Reshape C][Jelete~Q~ 
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NAME 


SALARY 


MANAGER 


DEPARTMENT 


jones 


8 003 


snith. 


househol d 


andersen 


6000 


Murphy 


toy 


nor 9 an 


10300 


lee 


cosmetics 


leu -is 


12000 


lang 


stationery 


nelson 


&G 00 


nurphy 


toy 


hoff nan 


18003 


Morgan 


cosnetics 


Ions 


?00 0 


Morgan 


cosnrtics 


nurphy 


800G 


snith 


houaehol d 


snith 


12000 


hoff nan 


stationery 


henry 


9000 


snith 


toy ! 


k 


|ncue □ 




Reshape Q 


_l 
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Gezielte Anfragen kann man stellen, indem man in einzelne Felder 
Konstanten einträgt. Konstanten können Zeichenketten, Zahlen oder Listen sein. 
Hier wollen wir beispielsweise die Gehälter der Abteilung "toy" ermitteln, wobei uns 
Name und Manager nicht interessieren. Deshalb haben wir dort Minuszeichen 
eingetragen: 



ffc- mp l oyftPS 



: - 

*Ury; SflLHRY 
Vlän&gtr: - 

.* *toy p 

Ifffsuftj: (6090 6000 90G0) 

I Un £ <?u* i Y e s Mo 

.* retr feue e\?ert delete 
\Evaluat i or>: PoaitVe Megated 
~£ya1 Ü 




Köve □ \fe shape Q Delete Q 



Add Hst 

i st of (Saluts i (£800 6000 9000) 

wm £3. 908 

Eva 1 B Hove □ Reshape □ De Tete □" 



Alle Formularfelder sind maussensitiv und können durch einfaches 
Anklicken in andere Felder kopiert werden. Das Ergebnis der Anfrage an die 
Datenbank kann einfach in einem anderen Formular weiterverwendet werden, da die 
Liste der Ergebnisse in dem Spezialfeld "Results" erscheint. So konnten wir die 
Summe aller Gehälter in der Abteilung "toy" ermitteln, indem wir in das Formular 
"Add List" die Liste der Gehälter durch Mausklicks kopiert haben. 



Das zugrundeliegende Modell: Constraints 

Bei der Evaluierung eines Formulars müssen hinreichend viele Felder mit 
Konstanten belegt sein. In den übrigen Feldern stehen Variablen. Alle Werkzeuge 
kennen ihre zulässigen Aufrufmodi, d.h. sie wissen, wann sie evaluierbar sind. Formal 
ist ein Aufrufmodus eine Teilmenge von Feldern, deren Belegung (mit Konstanten) 
genügt, um für die restlichen Felder eine endliche Lösungsmenge zu berechnen. 
Formulare für Datenbankanfragen z.B. sind - wie oben gezeigt - völlig ohne 
Konstanten evaluierbar, während "Plus" drei verschiedene Aufrufmodi besitzt, wobei 
jeweils mindestens zwei der drei Felder (mit Konstanten) ausgefüllt sein müssen. 

Allen Werkzeugen liegt ein einheitlicher Evalierungsmechanisnxus 
zugrunde, der auf Constraints beruht. Constraints sind Bedingungen, die für die 
Belegung der Formularfelder gelten müssen. Aufgrund von Constraints kann der 
Evaluierer Feldinhalte überprüfen bzw. aus den bereits ausgefüllten Feldern Werte 
für die übrigen Felder ableiten. Constraints können auf drei verschiedene Arten 
definiert sein: 
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• Die Menge der zulässigen Belegungen für die Formularfelder ist als 
endliche Liste von Tupeln gegeben (Datenbankrelation). 

• Zu einem Werkzeug existieren eine oder mehrere Berechnungsvorschriften 

(hier Lisp-Funktionen). Jede Berechnungsvorschrift gibt für einen 
Aufrufmodus an, wie man aus den angegebenen Konstanten die Lösungen 
für die Variablen berechnet. Damit durch verschiedene Berechnungsvor- 
schriften ein wohldefinierter Constraint gegeben ist, muß folgende 
Konsistenzbedingung erfüllt sein: Wenn aufgrund der angegebenen 

Konstanten mehrere Berecbuungsvorschriften anwendbar sind, müssen 
alle zum selben Ergebnis führen. Sind z.B. bei "Plus" alle drei Felder mit 
Konstanten gefüllt, so ist es gleichgültig mit welcher der drei Berech- 
nungsvorschriften die Summe überprüft wird. 

• Es ist eine Kombination von elementareren Constraints (Constraint-Netz) 
gegeben. Constraints können per Programming-by-Example kombiniert 
werden (siehe nächstes Kapitel). 

Unabhängig davon, welche Art von Constraints einem Werkzeug zugrunde 
liegt, gelten beim Evaluieren folgende Regeln: 

• Wurden zu wenige Felder ausgefüllt, so führt dies zu einer Fehlermeldung 

(underconstrained) . 

• Sind genügend, aber nicht alle Felder mit Konstanten belegt, so führt die 
Evaluierung eines Formulares immer zu einer Tabelle mit endlich vielen 
Variablenbelegungen (keine, eindeutige oder mehrere Lösungen). Die 
Überschrift der Tabelle enthält die Variablen des Formulars und die Zeilen 
der Tabelle enthalten die möglichen (zusammengehörigen) Werte- 
belegungen, die die Constraints des Werkzeugs erfüllen. 

• Wurden alle Felder des Formulars mit Konstanten belegt, so werden die 
Constraints überprüft und das Formular liefert das Ergebnis "True" bzw. 
"False". 

Das Ergebnis der Evaluierung eines Formulars wird grundsätzlich im 
Result-Fenster angezeigt. Manche Formulare (z.B. unsere Datenbank) besitzen ein 
spezielles Result-Feld, in dem dann auch das Ergebnis eingetragen wird. Eine 
eindeutige Lösung (d.h. die Tabelle besitzt genau eine Zeile) wird außerdem in die 
Felder des Formulars eingetragen (wie bei "Plus" demonstriert). 

Man kann die Werkzeuge auch kombinieren, um komplexere Anfragen zu 
stellen. Wir wollen z.B. ermitteln, welche Angestellten weniger als 800C $ verdienen. 
Dazu nehmen wir zu unserer Datenbank "Employees" noch das Formular "Less", 
kopieren in das Feld "Smaller Number" die Variable SALARY aus "Employees" und 
tragen bei "Greater Number" per Tastatur 8000 ein. Wenn wir nun bei einem der 
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beiden Formulare "Eval" anklicken, wird das System feststellen, da/? sowohl 
"Employees" als auch "Less" die Variable SALARY verwenden und daher gemeinsam 
evaluiert werden müssen. Auch die Reihenfolge der Evaluierung wird automatisch 
bestimmt. In unserem Beispiel kann "Less" nicht als erstes evaluiert werden, da der 
Vergleichswert noch nicht bekannt ist. Deshalb wird die Datenbank-Anfrage zuerst 
evaluiert und liefert als Zwischenergebnis eine (endliche) Tabelle von möglichen 
Belegungen für die Variablen NAME und SALARY. "Less" wird danach für jede Zeile 
der Tabelle einmal aufgerufen. Trifft das Prädikat für eine. Zeile nicht zu (Ergebnis 
ist "False"), so wird diese Zeile aus der Tabelle gestrichen. 



Employee s 
Han* : riflflE 
SvUry: SRLflPY 
ffaneger; - 

"toy" 

({‘anderaon 1 &GÖ0) ("nelson* bC 
UniQue: Yes flo 

Roö?; retrieve assert delete 

f ior [.■_ Pos .f t t ve Negated 

E wa 1 p Move Q Reshape Q Delete Q 



l nss_ 

Sn* Iler Nvnbir : SALARY 

renter tfunber: 0ÖG0 
RtsuItS : (&GBG 6Ö00) 

Ev&Iuat iöAi Po^ 1 1 i vp Negated 

L ■/ n 1 fl rove □ Pcthape P Delete □ 



Results 


HflHE 


SRLRRY 


anderson 


600G 


ne 1 son 


6000 


■ 


|riove □ 


Reshape □ 



Constraint-Netze 

Der Benutzer kann aus mehreren Formularen mit gemeinsamen Variablen 
ein Constraint-Netz aufbauen und evaluieren lassen. Die Knoten dieses Netzes bilden 
die Formulare; Kanten verlaufen zwischen zwei Formularen, falls sie wenigstens eine 
gemeinsame Variable haben. Wird bei einem der Formulare "Eval" angeklickt, so 
ermittelt das System zunächst die Ausdehnung des Constraint-Netzes. Dazu wird die 
transitive Hülle der Relation gemeinsame Variable gebildet. Da zunächst keine 
Reihenfolge auf der Menge der Formulare im Constraint-Netz definiert ist, muß zur 
Evaluierung eine geeignete Reihenfolge automatisch ermittelt werden. Dies geschieht 
aufgrund des Wissens über die Aufrufmodi der einzelnen Formulare; Es werden 
zunächst Formulare ausgewählt, die bereits evaluierbar sind, weil genügend Felder 
ausgefüllt sind. Dadurch erhält man schrittweise endliche Lösungsmengen für 
immer mehr Variablen, so daß nach und nach immer mehr Formulare evaluierbar 
werden (constraint propagation). 



Hierzu noch ein komplexeres Beispiel aus Query-by-Example [Zloof77]: 
Welche Angestellten verdienen mehr als ihre Manager? Wir füllen drei Formulare wie 
folgt aus: 
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Employees 




Löss 


Nana: EMPLOYEE 
Salary; SRl-EPlPL 
Nanager : MANAGER 
Bepartnent : * 

Results: trieuis* 12000 "long*) ChoFfn 
Unique; Yes Mo 

node; retrieue assert delete 
Evaluation; Positive Megated 




Snaller Hunter; EAL-MGR 
Greater Hunter: SRL-EMPL 
Results; (<70G0 12000) U0B00 16GG0)) 
Evaluation: Positive Negated 


Eval H Move tl Reshape D Delete □ 


* 


Evel □ Move □ Reshape Q Delete O 




Employees 




Resu 1 t S 


Wane.' MANAGER 
Salary; SBL-MGR 
Manager : - 
Bepartnent : - 

Results: f( Tong* 7000) ('fiorgan 1 10000) 
Unique; Yes Mo 

Hade: retrieve assert delete 
Evaluation: Positive Negated 


EMPLOYEE SflL-EMRL MR NRG ER EAL-NGH 


levis 12000 long 7000 

hoff nan 16000 norgan 10000 


I 


Eva! □ Move □ Reshape □ Delete Q 




Move D Reshape Q 



Es handelt sich hier um eine direkte Umsetzung der in Query-by-Example 
[Zloof77] vorgeschlagenen Lösung. Tatsächlich deckt das PERPLEX-System den 
Sprachumfang von Query-by-Example voll ab. Darüberhinaus können aber solche 
Anfragen noch eleganter durch Programming- by- Example gestellt werden, wie im 
nächsten Kapitel gezeigt wird. 

Auch graphische Ausgaben können in uniformer Weise über Formulare 
erzeugt werden. Hier zeigen wir, wie man beispielsweise die Gehälter aller 
Angestellten des "toy"-Departments in einem Kuchendiagramm anzeigen kann: 



Employees 




Nan*: NOME 
Sa/ary: SALARY 

Manager ; - 

Department : “toy“ 

Results; (C'anderson 1 6000) £' nelson* 60 
Unique: Yes lio 

Node : retrieve assert delete 
Evaluation; Positive Negated 


henry H2.SÜ) 

nelson (2S.£'?)V C M 

J^^^^anderson (28,6") 


Eval 0 Hove O Reshare Q Delete □ 




Pie Chari 


I ten: NAME 
t/alue: SALARY 

Results: ( ( “anderson* 6000) (“nelson' 60 


Eval 0 Move □ Reshape □Delete □ 


Move □ Reshape □ Delete □ 



Dazu werden einfach die Variablen, deren Lösungsmenge graphisch 
angezeigt werden soll, in das "Pie-Chart"-Formular eingetragen. Die Graphik wird 
dann in einem eigenen Fenster ausgegeben. Dieses Fenster kann - wie jedes Formular 
auch - beliebig verschoben ("Move"), vergrößert /verkleinert ("Reshape") und - wenn 
es nicht mehr benötigt wird - gelöscht werden ("Delete"). 

Es können auch Balkendiagramme und Funktionsgraphen erzeugt werden. 
[Huang86] schlägt ein ähnliches Verfahren vor, das aber auf graphische 
Aufbereitung von Datenbank-Anfragen beschränkt ist, während bei PERPLEX die 
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graphische Ausgabe für beliebige Berechnungen verwendet werden kann: 



Bet ween 

Value; X 

L over Bound ; - 3 . 14 
Uppe r Bound ; 3,14 
Seep: 0,314 

Results; (-3,14 -2 . 32 £0002 -2.512 -2.198 
Evaluation: Fnsltiv g Negated _ 

Eval Q Hove O Reshape Q Delete □ 



SINUS 

SlttX: SlliUS’X 

Results; ((-3,14 -0.001592540) (-2.B260G 
Unique; Yes fia 

Evaluation : Posi t jlye Negated 

Eva] □ Move □ Reshape QDelcte 0 



Curve 

X- fix is; K 

y-ftxis; SINUS -X 
Second y-ftxis: - 

Results: ((-3.14 -B ■ 001592546) (-2,62600 
, Eval B flaue Q Reshape Q Delete Q 




3. Definition neuer Werkzeuge durch Programming-by-Example 

Im letzten Kapitel wurde gezeigt, wie man existierende Werkzeuge über 
ihre Formular-SchnittstcMe aufruft, mit anderen Werkzeugen kombiniert und so 
bereits recht komplexe Berechnungen durchführen kann. Hier soll nun darauf 
eingegangen werden, wie man auf einfache Weise aus bestehenden Werkzeugen neue, 
immer komplexere Werkzeuge schaffen kann. 

Als Beispiel soll gezeigt werden, wie man ein Formular zum Berechnen 
eines prozentualen Zuschlages herstellt. Die Definition eines neuen Werkzeuges 
beginnt damit, daß man seine Formular-Schnittstelle beschreibt. Dazu wird im 
wesentlichen der Name des Werkzeuges sowie die Liste der Felder - also die formalen 
Parameter - in das Formular "New Tool" eingetragen. 



Ntw Tool 


fl 




Type: User-de Fined DB-£el st \ on Lisp 
Conatra int-f orn 
Hane : " Add percent" 

Field-/ : * Rnount" 

Field-2: "Percentage" 
field-J: "Total" 


Add percent 
Employees 
Plus 
Minus 






haue □ Reshape Q Close Q 



Es wird außerdem der Typ des Werkzeuges angegeben, d.h. es wird 
bestimmt, welche Sorte von Constraints das Ausfüllen des Formulars steuern soll. 
Datenbankrelationen werden zunächst leer angelegt und können dann nach und 
nach ausgefüllt werden. Beim Typ Lisp können anschließend für die verschiedenen 
Aufrufmodi Lispfunktionen angegeben werden. Hier soll aber auf die sog. 
benutzerdefinierten Werkzeuge eingegangen werden, die man auf bestehende 
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Werkzeuge zurückführt. 

Nach Anklicken von Create erscheint ein neuer Formulartyp im Werkzeug- 
Menü. Exemplare des neuen Formulars können in gewohnter Weise erzeugt und auf 
dem Bildschirm plaziert werden. Es kann auch bereits "Eval" angeklickt werden, 
allerdings wird dann lediglich der Benutzer nach der Lösung gefragt, da ja noch 
keine Constraints definiert wurden. Auf diese Weise ist es aber möglich, auch 
unvollständig spezifizierte Algorithmen zur Ausführung zu bringen (inkrementeile 
Programmierung, top-down design). 

Regeln zum Ausfüllen der Formularfelder definiert man nun, indem man 
einfache Beispiele vorrechnet (Programming-by-Example). Als Beispiel wählt man ein 
teilweise ausgefülltes Formular. Das Vorrechnen geschieht dann, indem man einfach 
die existierenden Werkzeuge verwendet, um aus den bereits ausgefüllten Feldern die 
übrigen zu ermitteln und/oder die ausgefüllten Felder auf ihre Konsistenz hin zu 
überprüfen. Im allgemeinen Fall demonstriert man so die Arbeitsweise eines 
Algorithmus’ auf verschiedenen Eingabedaten und das System generiert daraus ein 
Programm. 



T OOLS 

Md percent 
Employees 
Plus 
Minus 
Times 
Divide 
Per cent 
Sinus 

Current Date and 
Date and Time 

Equal 

flovc D Reshape O 



Add per coat 

Select 

Arrange in Package (s) 
Show Usage 
Special Fields 
Inspect 

Give Example! x 
Animate Pule 
Show Rule 
Delete Pule 
Delete all Rules 
Trace on 

Time 




In unserem Fall geht man im einzelnen folgendermaßen vor: Aus dem Menü 
der möglichen Operationen auf dem Werkzeug "Add percent” wählt man "Give 
Example" und erzeugt so ein dick umrandetes Beispielsformular, das man in 
gewohnter Weise auf dem Bildschirm plazieren kann. In dieses Formular wird das 
gewünschte Beispiel eingetragen: Es werden die Felder "Amount" und "Percentage" 
ausgefüllt. 
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Rd d percent 



M 



TV 



■i 



shape □DeTftg □ 



\ 




I 



ttovg D Peshapg □ DrTetg 




quotisnTT ß 

jEyaj D ytiovc □ Reshape □ Delete Ö 




limns 

first Fsctc 
Sseond f& ct'br : 

Fr oduc t : 

E^al □ npin? J 



□ Delete Q 



Unter Benutzung der existierenden Werkzeuge wird nun Schritt für Schritt 
- wie hier durch Pfeile angezeigt - der Wert für das Feld "Total” errechnet: Dter 
Prozentsatz wird zunächst (per Mausklick) in ein "Plus"-Formular kopiert. Als 
zweiter Summand wird 100 eingetragen (eingetippt) und durch Anklicken von "Eval" 
die Summe 114 ermittelt. 114 wird in ein "Divide"-Formular kopiert und durch 100 
geteilt. Das Ergebnis ist der Faktor 1.14, mit dem der Grundbetrag zu multiplizieren 
ist. Dazu werden dieser Faktor sowie der Basisbetrag 200 in ein "Times"-Formular 
kopiert. Das Ergebnis 228 wird dann schließlich zurück in das Beispielsformular 
kopiert. Damit ist das Vorrechnen des Beispiels beendet, man klickt "Define” bei dem 
Beispielsformular an und alle beteiligten Formulare verschwinden wieder. 

Das PERPLEX-System hat den Benutzer beim Vorrechnen des Beispiels 
beobachtet und daraus eine Regel abgeleitet, wie das Formular auszufüllen ist. Daher 
kann anschließend das "Add percent" Formular verwendet werden. Werden die Felder 
"Amount" und "Percentage" mit irgendwelchen Zahlenwerten ausgefüllt und sodann 
"Eval" angeklickt, so wird das Feld "Total" automatisch ausgefüllt. Eine mögliche 
Erklärung dafür, daß das neue Formular auf diese Art verwendet werden kann (aus 
gegebenen "Amount" und "Percentage" wird "Total" errechnet), wäre, daß das 
PERPLEX-System alle Mausklicks registriert hat, die der Benutzer beim Vorrechnen 
des Beispiels gemacht hat, und sie nun simuliert. In der Tat wird aber die aus dem 
Beispiel abgeleitete Regel auf einem viel höheren Abstraktionsniveau dargestellt. Sie 
wird nämlich als Constraint-Netz dargestellt, das die Abhängigkeiten zwischen den 
drei Feldern des Formulars beschreibt: 
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Aus diesem Grunde ist es möglich, das "Add percent"-Formular auch auf 
andere Weise zu verwenden: Aus der Angabe von "Total" und "Percentage" kann 
"Amount" ermittelt werden, oder aber aus "Total" und "Amount" wird "Percentage" 
errechnet. Der Evaluierer findet nämlich (wie oben beschrieben) jeweils eine 
geeignete Reihenfolge, um die einzelnen Formulare zu evaluieren und so die 
Variablen nach und nach zu instantiieren. 



Add percent 




Add percent 


Rnouftt i 2Ö9 




ßrtount : 2Ö0 


Percenter: PERCENT R GE 




ParcantAQt : 14 


Total: 22Q 




Total : 228 


Euol O Hove O Reshape □ Delete □ 




Ewal □ Holt« Q Rashape □ Delete D 



Die Ableitung des Constraint-Netzes aus der Beispielsrechnung geschieht 
folgendermaßen: Zunächst werden alle verwendeten Formulare als Knoten des Netzes 
gewählt. Felder, deren Wert eingetippt wurde, werden mit einer entsprechenden 
Konstante ausgefüllt. Für jeden Kopiervorgang wird in Start- und Zielfeld dieselbe 
Variable eingetragen. Insbesondere werden für Kopiervorgänge zwischen dem 
Beispielsformular und anderen Formularen die Namen der formalen Parameter in 
das Constraint-Netz eingetragen. 

Für das so generierte Constraint-Netz kann anschließend ermittelt 
werden, welche der formalen Parameter gegeben sein müssen, damit für die übrigen 
eine Lösung ermittelt werden kann. Dazu wird für jede Teilmenge der formalen 
Parameter die Vorgehensweise des Evaluierers durchgespielt und geprüft, ob die 
Aufrufmodi der verwendeten Formulare die Berechnung einer Lösung für das Netz 
ermöglicht. Auf diese Weise werden die Aufrufmodi des neu definierten Werkzeuges 
ermittelt und abgespeichert, so daß bei einer falschen Verwendung des Werkzeuges 
sofort eine Fehlermeldung erfolgen kann. Die Grundlagen für eine formale Theory of 
Directionality finden sich in [Reddy86], 



Vorteile von Programming-by-Example 

Aus diesem ersten, sehr einfachen Beispiel lassen sich bereits eine Reihe 
von Vorteilen des Verfahrens, insbesondere unserer speziellen Auffassung des bereits 
arg strapazierten Begriffs Programming-by-Example erkennen: 
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• Zur Formulierung von Beispielrechnungen gibt es keine formale Sprache, 
die ja immer die Gefahr in sich bergen würde, daß das Formulieren von 
Beispielen letztlich ebenso schwierig ist wie die Verwendung einer 
Programmiersprache. Stattdessen werden die Beispiele im wesentlichen 
durch Gestiken mit der Maus vorgerechnet. 

• Beim Vorrechnen der Beispiele werden konkrete Zwischenergebnisse 
berechnet. Die Verwendung von Variablen wird dadurch auf ein Minimum 
reduziert. Insbesondere kann in den meisten Fällen darauf verzichtet 
werden*, mehrere Formulare mit gemeinsamen Variablen gleichzeitig zu 
evaluieren, stattdessen werden die Formulare einzeln evaluiert und die 
konkreten Zwischenergebnisse werden kopiert. 

• Dadurch, daß das Beispiel nicht etwa in einem Editor formuliert wird, 
sondern sofort durchgerechnet wird, stellt das Vorrechnen bereits einen 
ersten Test dar. Fehler können frühzeitig erkannt oder vermieden 
werden, da statt mit Variablen, deren Wert nur im Kopf des Benutzer 
bekannt ist, direkt mit Werten gearbeitet wird. Allerdings sollte bei der 
Wahl einer geeigneten Beispielsaufgabe darauf geachtet werden, daß nicht 
zufällig mehrere gleiche Werte in der Rechnung auftreten. Dann ist es 
nämlich nicht gleichgültig, mit welchem Wert weitergearbeitet wird, da für 
das System der Platz entscheidend ist, wo der Wert steht. (Pfeile zwischen 
den Werten werden bei der Definition des Werkzeuges noch nicht 
angezeigt.) 

• Die Programmierung eines neuen Werkzeuges ist ebenso einfach wie die 
pure Benutzung der Werkzeuge. Wird also der Benutzer mit dem Problem 
konfrontiert, einen prozentualen Zuschlag berechnen zu müssen, so kann 
er, anstatt die Berechnung einmalig durchzuführen, ebensogut dem 
Problem einen Namen geben und die Berechnung beispielhaft für ein 
neues Werkzeug durchführen. 

Auf Wunsch wird dem Benutzer im einzelnen angezeigt, wie das neu 
definierte Formular evaluiert wird. Es werden dann die beim Vorrechnen 
verwendeten (Hilfs-)Formulare angezeigt. Kopiervorgänge werden durch einen Pfeil 
von Feld zu Feld angezeigt, Mausklicks durch Färben des entsprechenden 
Bildschirmbereiches. Der Ablauf kann in Einzelschritten vorgespielt oder in 
verschiedenen Geschwindigkeiten durchlaufen werden (Algorithmen- Animation). Zur 
Überwachung des Programmablaufs muß sich der Benutzer also nicht irgendeine 
interne Repräsentation zu eigen machen, sondern die Aktionen werden mit genau 
den "Sprachmitteln" dargestellt, mit denen der Benutzer ursprünglich sein Beispiel 
vorgemacht hat. Dies entspricht der Forderung, daß man ein Programm in einer 
höheren Programmiersprache auf der Ebene des Quellcodes tracen und debuggen 
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kann, und nicht etwa im Fehlerfall mit Registern, Hexadezimaladressen und core- 
dumps konfrontiert wird. 

Im PERPLEX-Sytem wurde dementsprechend auch bewußt auf eine externe 
Darstellung von Regeln verzichtet: Per Beispiel definierte Regeln können nicht in 
irgendeiner Syntax textuell angezeigt oder ausgedruckt werden. Sie werden 
stattdessen dargestellt, indem in das Formular die Originalbeispiele eingetragen 
werden und die Evaluierung schrittweise angezeigt wird ("Animate Rule" im 
Operationsmenü). Es ist geplant, Modifikationen an bestehenden Regeln durch 
Eingriffe in den Programmablauf vorzunehmen, anstatt mit einem Texteditor eine 
textuelle Repräsentation zu modifizieren. In engem Zusammenhang damit steht die 
Implementation eines komfortablen UNDO/REDO-Mechanismus, der es erlauben 
würde, den Algorithmus vorwärts und rückwärts laufen zu lassen und so den 
Programmablauf wie einen Videofilm bis zu einer interessanten Stelle zu spulen. 

Als nächstes soll nochmals ein Beispiel aus dem letzten Kapitel 
aufgegriffen werden und gezeigt werden, wie es sich mit Programming-by-Example 
einfacher lösen läßt. Es sollte festgestellt werden, wer mehr verdient als sein 
Manager. Die ad-hoc Anfrage verwendet bereits drei Variablen und stellt damit schon 
eine kompliziertere Aufgabe dar, die wir dem ins Auge gefaßten Endbenutzer nicht 
zumuten wollen. 

Für die Lösung mit Programming-by-Example wird zunächst ein neues 
einstelliges Prädikat "Earns more than Manager" definiert. In das Beispielsformular 
tragen wir "lewis" ein und müssen nun lediglich überprüfen, ob das Prädikat auf ihn 
zutrifft. 
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Dazu nehmen wir uns ein "Employees"-Formular, kopieren den Namen 
"lewis" hinein und evaluieren. Es erscheint "long" als Manager und das Gehalt 12000. 
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Wir kopieren "long" in ein weiteres "Employees'-Formular, evaluieren es und 
erhalten als Gehalt von "long" 7000 $. Schließlich kopieren wir die beiden Gehälter in 
ein "Less"-Formular und überprüfen, ob tatsächlich das Gehalt von Lewis größer ist. 

Mit dem neu definierten Formular können wir nun von jedem beliebigen 
Angestellten feststellen, ob er mehr verdient als sein Vorgesetzter. Wir können aber 
auch eine Variable in das Formular "Earns more than Manager" eintragen und so alle 
Angestellten feststellen, auf die die Bedingung zutrifft. Das PERPLEX-Sytem hat 
nämlich aus dem Beispiel genau das Constraint-Netz abgeleitet, das im vorigen 
Kapitel für die ad-hoc Anfrage verwendet wurde! 
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Zwar mußte bei dieser Lösung ein neues Prädikat definiert werden, was 
sicherlich zunächst etwas zusätzlichen Aufwand bedeutet. Auf der anderen Seite ist 
es aber für einen Endbenutzer sicherlich wesentlich einfacher, Schritt für Schritt 
mit konkreten Zwischenergebnissen zu arbeiten, als einen komplexen, mit mehreren 
Variablen ausgedrückten Zusammenhang zu überschauen. Das wird besonders 
deutlich, wenn man sich vorstellt, daß das Beispiel noch erweitert würde. 
Beispielsweise könnte es erwünscht sein, auch noch die Differenz der Gehälter zu 
ermitteln. Während es ein leichtes ist, mit den beiden Zahlen vor Augen weitere 
Berechnungsschritte anzuhängen, erhöhen sich mit jeder neuen Variablen rapide die 
Anforderungen an die Abstraktionsfähigkeit des Endbenutzers. 

Während Zloof [Zloof77] sich darauf beschränkt, dem Benutzer den Begriff 
der Variable didaktisch näherzubringen, indem er Variablen als "example elements" 
bezeichnet und dementsprechend geeignete Namen vergibt, wird in unserem System 
anstelle von Variablen mit konkreten Werten gearbeitet, so daß das Schlagwort 
Programming-by-Example wirklich gerechtfertigt scheint. 

Das letzte Beispiel könnte den Eindruck erwecken, daß man bereits eine 
Lösung kennen muß, um ein Beispiel vorzurechnen, also schon einen Angestellten 
kennen muß, der mehr verdient als sein Vorgesetzter. In vielen Fällen definiert man 
gerade ein neues Werkzeug, um festzustellen, ob es überhaupt eine Lösung gibt. 
Daher ist es durchaus erlaubt, mit falschen Beispielen zu arbeiten. Würde man 
beispielsweise "jones" überprüfen, so würde man schließlich testen, ob 12000 kleiner 
als 8000 ist. Auf die letztlich abgeleitete Regel hat das aber keinen Einfluß. 

Das nächste Beispiel zeigt, wie man Datenbankanfragen mit grouping 
elegant lösen kann, ohne daß ein spezielles Sprachkonstrukt nötig ist, wie das zum 
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Beispiel in [Chamb77] oder Query-by-Example der Fall ist ("group-by" Operator). 
Nehmen wir an, es soll zu jedem Department die Summe der Gehälter ermittelt 
werden. Wir definieren uns ein neues Werkzeug "Sum of Salaries" mit den beiden 
Parametern DEPARTMENT und SUM. Als Beispiel führen wir vor, wie man zum 
Department "toy" die Summe der Gehälter ermittelt: Man kopiert "toy" aus dem 
Beispielsformular in ein "Employees'-Formular und führt dann die Anfrage genau so 
durch, wie im letzten Kapitel bereits beschrieben. Das Ergebnis wird dann wieder in 
das Beispielsformular kopiert. Mit Hilfe des neuen Werkzeugs kann man nun zu einem 
bestimmten Department oder aber auch zu allen Departments die Summe der 
Gehälter ermitteln. 

Schließlich soll noch ein Beispiel gezeigt werden, das Rekursion verwendet. 
Es soll ein Prädikat Superior definiert werden, das angibt, ob ein Angestellter - 
eventuell über mehrere Hierarchiestufen - Vorgesetzter des anderen ist. Zum 
Beispiel ist Smith der direkte Vorgesetzte von Jones; Morgan steht 3 Stufen höher in 
der Hierarchie als Jones. In beiden Fällen soll das Prädikat Superior zutreffen. 

Wir tragen daher zunächst "jones" und "smith" in das Beispielsformular ein 
und überprüfen, ob tatsächlich ein direktes Vorgesetztenverhältnis besteht, indem 
wir die beiden Namen in ein "Employees'-Formular kopieren und "Eval" anklicken 
(links): 
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Anschließend wird auch das zweite Beispiel demonstriert: "jones" und 
"morgan" werden in das Beispielsformular eingetragen, "jones" wird in ein 
"Employees"-Formular kopiert und sein direkter Vorgesetzter wird ermittelt. Es 
erscheint "smith” im Manager-Feld. Nun muß (rekursiv) überprüft werden, ob 
"morgan" ein direkter oder indirekter Vorgesetzter von "smith" ist. Dazu nehmen wir 
ein "Superior"-Formular und kopieren "smith" und "morgan" hinein. Beim Evaluieren 
stellt das System fest, daß gerade das Formular verwendet wird, das doch soeben 
erst definiert wird. Daher nimmt es an, daß die existierenden Regeln noch nicht 
vollständig sind und fragt den Benutzer nach der Antwort. Wir antworten mit "yes", 
so daß "true" als Ergebnis erscheint. Damit ist auch das zweite Beispiel vollständig. 

Aus den zwei Beispielen werden zwei Regeln in Form von Constraint-Netzen 
abgeleitet. Wird das "Superior'-Formular nun verwendet, so werden nacheinander 
Lösungen für beide Netze gesucht. Die Vereinigung der Lösungsmengen bildet dann 
die Lösung für Superior. Die Auswertung einer Regel (insbesonders einer rekursiven) 
wird abgebrochen, wenn ein Werkzeug keine Lösung für seine Variablen findet (z.B. 
bei einer Datenbank-Anfrage) oder ein vollständig ausgefülltes Formular (z.B. ein 
Prädikat wie "Less") zu "False" evaluiert. Dadurch kann man bedingte Anweisungen 
programmieren, indem man an dem gewählten Beispiel zuerst demonstriert, daß die 
gewünschte Bedingung erfüllt ist. Ebenso können so Abbruchkriterien für Rekursion 
angegeben werden. In unserem obigen Beispiel endet die Rekursion, wenn zu einem 
Angestellten kein Vorgesetzter mehr gefunden wird. 

Das Beispiel zeigt auch eine Programmiertechnik, die beim Programming- 
by-Example sinnvoll ist: Da man nur einzelne Werte zwischen dem Beispielsformular 
und den übrigen Formularen kopieren kann, muß man im Beispielsformular 
mindestens soviele Parameter vorgeben, daß sich eine eindeutige Lösung ergibt. Im 
Extremfall trägt man alle Parameter ein und braucht lediglich zu überprüfen, ob die 
Constraints erfüllt sind. In unserem Beispiel leitet das PERPLEX-System daraus ein 
beliebig verwendbares Werkzeug ab: Man kann mit dem "Superior"-Formular alle 
Vorgesetzten eines bestimmten Angestellten, alle Untergebenen eines bestimmten 
Vorgesetzten oder aber alle Vorgesetzten aller Angestellten bestimmen. 

Sicherlich ist Rekursion für den Endbenutzer kein leicht verständliches 
Konzept. Sie wurde aber zugelassen, damit jede berechenbare Funktion 
programmiert werden kann. Es ist geplant, das PERPLEX-System so zu erweitern, daß 
sich wiederholende Handlungsfolgen in den demonstrierten Beispielen erkannt 
werden und daraus rekursive Regeln automatisch abgeleitet werden. Ein ähnlicher 
Ansatz wird in [Bauer79] verfolgt, allerdings werden dort die Beispielsrechnungen in 
einer formalen Beschreibungssprache spezifiziert. 
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4. Zusammenfassung und Einbettung 

Es wurde das PERPLEX-System vorgestellt, das dem Endbenutzer erlaubt, 
auf einfache Weise eigene Anwendungen zu programmieren. Die Programmierung 
geschieht nicht in einer formalen Sprache, sondern durch Vorrechnen von Beispielen 
mit Hilfe der vorhandenen formularorientierten Werkzeuge. Der Einsatz des 
PERPLEX-Systems bietet sich dementsprechend vor allem im Bürobereich an, wo 
ohnehin bereits viele Tätigkeiten durch Formulare formalisiert sind. 

In der Tat wurde PERPLEX als Ergänzung zum Vorgangssystem DOMINO 
[Krei84] [KrW86] entwickelt. DOMINO verwaltet arbeitsteilige Abläufe in 
Organisationen (sog. Vorgänge), indem es Formulare zwischen Bürosachbearbeitern 
nach einer festg'e'legten Vorgangsbeschreibung über electronic mail weiterleitet. Der 
Sachbearbeiter, der an einem solchen Vorgang beteiligt ist, bekommt auf seiner 
lokalen Workstation ein teilweise ausgefülltes Formular vorgelegt. Seine Aufgabe 
besteht nun darin, aufgrund der bereits ausgefüllten Felder und der auf der 
Workstation vorhandenen Daten die übrigen Felder des Formulars auszufüllen und so 
seinen Teilschritt im Vorgang durchzuführen. 

DOMINO und PERPLEX wurden erfolgreich miteinander gekoppelt, so daß 
der Sachbearbeiter die lokalen Werkzeuge von PERPLEX (Datenbanken, 
Taschenrechnerfunktionen, ...) verwenden kann, um sein Formular auszufüllen. 
Darüberhinaus wird er beim Ausfüllen beobachtet und es werden Regeln abgeleitet, 
die auf Wunsch in Zukunft zum automatischen Ausfüllen der Formulare verwendet 
werden können. Vorgangsformulare sind nämlich Werkzeuge wie alle anderen, deren 
Name und Felder allerdings vom DOMINO-System vorgegeben werden. Geeignete 
Beispiele für Programming-by-Example werden einfach dadurch an den 
Sachbearbeiter herangetragen, daß er regelmäßig an demselben Vorgang beteiligt 
ist. Im Idealfall braucht sich der Sachbearbeiter kaum bewußt zu sein, daß er 
programmiert: Er muß lediglich die ihm zugesandten Formulare mit den PERPLEX- 
Werkzeugen bearbeiten und nach einiger Zeit werden für alle vorkommenden Fälle 
Bearbeitungsregeln abgeleitet sein. 
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EINE WISSENSBASIERTE SCHNITTSTELLE - 

VERMITTLER ZWISCHEN MENSCH UND MASCHINE 

Thomas Fehrle, Universität Stuttgart 

Zusammenfassung: Der Einsatz von Wissen über Mensch und Maschine ermöglicht 
in natürlichsprachlichen Schnittstellen zu Expertensystemen benutzerangepaßtes und koopera- 
tives Verhalten. Die Möglichkeiten, die sich durch Integration von Dialogverwaltung, Wissen 
über die Fähigkeiten, die im System vorhanden sind, und Benutzermodellierung ergeben, wer- 
den am Beispiel des wissensbasierten Systems KEYSTONE , das Auskunft über PC Produkte 
gibt, vorgestellt. 

Schlüsselwörter: Benutzerschnittstelle, Verarbeitung natürlicher Sprache 
1. Einleitung 

Expertensysteme können heute bereits ihr Wissen und ihre Fähigkeiten in vielen 
Anwendungen dem Benutzer zur Verfügung stellen. Natürlichsprachliche Schnittstellen ermög- 
lichen auch »naiven« Benutzern die Nutzung von wissensbasierten Systemen ohne größeren 
Lernaufwand. Aus Benutzersicht tritt dabei das Problem auf, wie man an die gewünschte In- 
formation gelangt. »Naive« Benutzer haben meistens von einem natürlichsprachlichen System 
eine falsche Modellvorstellung. Das System wird implizit einem menschlichen Dialogpartner 
bzw. einem menschlichen Experten gleichgesetzt. Von ihm wird mehr erwartet als es kann, 
was allein durch die Rolle des Benutzers als Informationssuchenden und des Systems als In- 
formationsgebenden suggeriert wird. Der Benutzer erwartet eigentlich von einem derartigen 
System nicht nur die gewünschten Informationen, sondern auch die Information darüber, wie 
er sie erhalten kann, und vielleicht auch darüber, wie relevant eine erhaltene Information in 
einem bestimmten Sachverhalt ist. An Beispielen mangelt es nicht, die zeigen, wie unglücklich 
Dialoge verlaufen können, wenn der Benutzer eine falsche Modellvorstellung von einem natür- 
lichsprachlichen System hat [1]. Aufgabe einer wissensbasierten Schnittstelle soll es sein, durch 
kooperatives Verhalten und durch Angabe der Fähigkeiten des zugrundeliegenden Systems das 
Modell des Benutzers über das System zu korrigieren. 

Dem Benutzer sollte beim Umgang mit dem System vor allem deutlich werden: 

- Ein Expertensystem kann nur auf das spezielle Expertenwissen zurückgreifen. All- 

1 KEYSTONE wird als Kooperationsprojekt der IBM Deutschland GmbH, Abteilung IS Informatik Zentrum Program- 
me mit der Universität Stuttgart, Institut für Informatik, Abteilung Dialogsysteme entwickelt. 
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gemeines Weltwissen steht nur begrenzt zur Verfügung. 

- Die Fähigkeit, natürliche Sprache zu verstehen, ist eingeschränkt. 

- Problemlösungen sind nur dann relevant, wenn die getroffenen Vorannahmen des Be- 
nutzers bei der Problemformulierung mit dem Wissen des Systems übereinstimmen. 

Im folgenden soll die Möglichkeit der Erweiterung eines Systems um Wissen über 
den Dialog, die Fähigkeiten des Systems und die Fähigkeiten des Benutzers dargestellt und 
über die Auswirkungen berichtet werden. 

Diese Darstellung erfolgt an Hand des wissensbasierten Systems KEYSTONE, wel- 
ches sich als ein natürlichsprachliches Auskunftssystem über PC Produkte besonders an Gele- 
genheitsbenutzer wendet, die keine Erfahrung im Umgang mit diesem System besitzen. 

2. Das wissensbasierte Exoertensvstem KEYSTONE V.1.0. 

KEYSTONE V.1.0 [2] ist die erste Entwicklungsstufe eines wissensbasierten In- 
formationssystems über PC Produkte. Der Anwendungsbereich des Systems liegt in der Unter- 
stützung des Benutzers 

- beim Erwerb von Kenntnissen über PC Produkte. 

- bei der Klärung von Sachfragen über PC Produkte. 

- bei der Entscheidungsfindung über Hardware bzw. Software, die für den Einsatz beim spe- 
zifischen Kunden geeignet ist. 

Bei der Gestaltung der Mensch-Maschine-Schnittsteile für das System soll ein 
benutzerangepaßtes, kooperatives Verhalten erreicht werden, damit eine professionelle Nut- 
zung des Systems genauso wie eine erstmalige Nutzung problemlos erfolgen kann. Eine Nut- 
zung des Systems soll ohne eine einführende Unterweisung erfolgen können. 

Der Prototyp KEYSTONE V. 1 .0 wurde in der Programmiersprache PROLOG auf 
einem IBM PC/AT02 implementiert. 

2.1 Die Architektur von KEYSTONE V. 1.0. 

Der Prototyp KEYSTONE in der Version 1.0 (vgl. Abbildung 1) beinhaltet die 
Dialogkomponente KEYBIT 2 [3]. Sie führt den Dialog mit dem Benutzer, wertet dessen natür- 
lichsprachliche Eingaben, die in geschriebener Form vorliegen, syntaktisch und semantisch aus 
und transformiert sie in eine interne Repräsentation. Zur syntaktischen Auswertung einer na- 
türlichsprachlichen Eingabe benötigt die Dialogkomponente KEYBIT Zugriff auf ein 
Grundformenlexikon, auf eine Morphologiekomponente und auf Grammatikregeln. Für den 

^KEYBIT wurde an der Universität Stuttgart, Institut für Informatik, Abteilung Dialogsysteme im Rahmen des Projekts 
KEYSTONE entwickelt. 
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Aufbau der internen Repräsentation einer natürlichsprachlichen Eingabe wird auf interpreta- 
tives und konzeptionelles Wissen aus der Wissensbasis zurückgegriffen. In einem zweiten Ver- 
arbeitungsschritt überführt KEYBIT eine Antwortstruktur, die von der Problemlösekomponen- 
te erstellt wurde, in eine natürlichsprachliche Form und gibt sie als Antwort auf die Benut- 
zereingabe aus. Der Dialog wird dabei grundsätzlich vom Benutzer gesteuert. 




A 



Benutzer 




A #=£ B A ruft B auf 

A — * B A verwendet Wissensbasis B 

Abbildung 1 Architektur von KEYSTONE 

Die ProblemlÖsekomponente interpretiert die interne Problemstruktur, findet 
durch Inferenzmechanismen und Manipulation des Wissens aus der Wissensbasis eine Problem- 
lösung, die in der internen Antwortstruktur der Dialogkomponente übergeben wird. 

In der Wissensbasis ist das Expertenwissen in Form von Fakten und Inferenzregeln 

gespeichert. 



Assertionales Wissen: Die Wissensbasis besteht aus einer Hierarchie von Objekt- 
typen. Einzelne Objekttypen können in Relationen zueinander stehen. Objekttypen können 
durch Attribute und deren Werte näher bestimmt werden. 

Bsp 1: In (LI) wird angegeben, wie im System der Fakt gespeichert wird, daß die 
Relation » runs_under « zwischen dem Datenbanksystem »Everyman 4.05« und dem Betriebssy- 
stem » DOS 2.1 « gilt. 

( 1.1 ) fact_rel( runs _under,’ Everyman 4.05\ , DOS 2.V). 

ln (1.2) wird der Fakt, das Datenbanksystem »Everyman 4.05« besitzt die Organisations form 
»netzwerkartig«, beschrieben. 

(1.2) fact _attr(org_form,' Everyman 4.05 ’ -> netzwerkartig). 
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Konzeptionelles Wissen: Die Wissensbasis enthält die Beschreibung möglicher Rela- 
tionen zwischen Objekttypen und möglicher Attribute bzw. Attributwerte, die für einen Ob- 
jekttyp gültig sein können. 

Bsp 2: In (2.1) wird die Beschreibung der Relation »runs_under« als Teilmenge 
des karthesischen Produkts der Menge der dem System bekannten Anwendungssoftware mit der 
Menge der Betriebssysteme angegeben. 

( 2.1 ) def_rel( runs _under ,' Anwendungssoftware' x 'Betriebssystem' ). 

In (2.2) wird das Attribut » org_form « in einem Fakt allen Objekttypen zugeordnet , die vom 
Typ »Datenbanksystem« sind, und in (2.3) wird dessen Wertebereich in einer Regel beschrieben. 

( 2.2) def_attr( org _form,' Datenbanksystem' -> org _jorm_domain). 

( 2.3 ) def _domain( org _J or m_d omain, X ) :- 

member( X,[ relational, 'index- sequentiell' , hierarchisch, netzwerkartig]). 

Interpretatives Wissen: Zusätzlich enthält die Wissensbasis in KEYSTONE Abbil- 
dungsvorschriften von natürlichsprachlichen Konstrukten in interne Darstellungen. Dazu gehö- 
ren etwa die Transformationsregeln für das Prädikat eines Satzes in die entsprechende interne 
Relation und Regeln zur Interpretation von Nominal- und Präpositionalphrasen. 

Bsp.3: In (3.1) wird beispielhaft angegeben, daß innerhalb KEYSTONE das Prädi- 
kat » laufen « in » runs_under « abgebildet werden kann, wobei das Subjekt des Satzes als erstes 
Argument und das Präpositionalobjekt als zweites Argument bestimmt ist. 

(3.1) cf_map( laufen,( sub jekt,praepob j ekt: instrumental ), 

[ runs_under,( argl :Sub jekt,arg2:( Praepob j ekt .'instrumental ))]). 

3. Erweiterung der Dialogkomponente KEYBIT 

Die Dialogkomponente KEYBIT wird in der 2. Ausbaustufe um Wissen über 
Dialoghistorie, Fehlerbehandlung, Benutzer und Klärungsstrategien und um die Komponenten 
zur Bearbeitung des entsprechenden Wissens erweitert (vgl. Abbildung 2). Zusätzlich zum na- 
türlichsprachlichen Dialog soll der Benutzer auch über einzelne Schlagworte Informationen 
erhalten. Innerhalb der Beschreibung eines Schlagwortes erhält der Benutzer die Gelegenheit, 
durch direkte Manipulation zu weiteren Schlagworten zu verzweigen. Dieses als Browser be- 
zeichnete Navigationswerkzeug soll »das Blättern in einem Katalog« simulieren. Die Abarbei- 
tungsfolge zwischen den einzelnen Komponenten regelt der Dialogmonitor. 

3.1 Der Dialogverwalter und die Dialoghistorie 

Neben Verwaltungsaufgaben, Speicherung des Dialogs und Zugriff auf die aktuell- 
sten Benutzereingaben und Systemantworten zur Behandlung von sprachlichen Ellipsen und 
zur Auflösung von Referenzen muß der Dialogverwalter den aktuellen Bezugspunkt bzw. Fo- 
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Abbildung 2 Erweiterte Architektur von KEYSTONE 



kus bestimmen. Im Fokus sollen Objekte und Attribute von Objekten stehen, über die der Be- 
nutzer nähere Informationen einholen will. Die Bestimmung des aktuellen Fokus erfolgt mit- 
tels heuristischen Wissens, welches auf die aktuelle Eingabe des Benutzers und auf den bishe- 
rigen Fokus angewandt wird. Dieses Wissen wird in Form von Produktionsregeln repräsentiert. 
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die datengesteuert ausgewertet werden. 

Bsp.4: Von den Regeln (R4.1) bis (R4.4), die beispielhaft aus dem gesamten Re- 
gelsatz zur Bestimmung des Fokus herausgegriffen sind , berechnen die anwendungsunabhängi- 
gen Regeln (R4.1) und (R4.4) den Fokus auf Grund des Kontextes , während die sachspezi fische 
Regeln (R4.2) und (R4.3) den Fokus durch Wissen über die PC-Weit bestimmt. 



(R4.1) 


Wenn 


ein Objekt X, welches in einer Benutzeranfrage angesprochen wird, die 
intern durch eine zweistellige Relation repräsentiert wird, im Fokus 
steht 




dann 


wird das Objekt X dem neu zu bestimmenden Fokus zugeordnet. 


(R4.2) 


Wenn 


ein Objekt X, welches in einer Benutzer anfr age angesprochen wird, die 
intern durch eine zweistellige Relation repräsentiert wird, nicht im Fo- 
kus steht 




und 


das Ob jekt X gehört zur minimalen Standardausrüstung eines PC 




dann 


markiere das Objekt X als Kennzeichen dafür, daß es sehr unwahr- 
scheinlich dem Fokus zugeordnet werden wird 


(R4.3) 


Wenn 


kein Fokus neu bestimmt werden konnte 




dann 


werden dem Fokus alle unmarkierten Objekte aus der Benutzer an fr age 
zugeordnet 


(R4.4) 


Wenn 


kein Fokus neu bestimmt werden konnte 




dann 


werden dem Fokus alle Objekte aus der Benutzer an fr age zugeordnet 



Der Fokus liefert Wissen zur Antwortgestaltung (siehe Bsp.5), zur Bildung von al- 
ternativen Anfragen im Nein- Fall und zur Klärung von Mehrdeutigkeiten (vgl. Kap.3.3.). 

Bsp.5: Auf die Frage (5.1) erhält man die Antwort (5.2) unter Bezugnahme von 
»DOS« im Fokus. 

(5.1) Läuft ein netzwerkartiges Datenbanksystem unter DOS? 

(5.2) Ja , und zwar unter 

DOS Version u.v und DOS Version x.y 

(5.3) enthält die Antwort auf (5.1) unter Bezugnahme von »netzwerkartigem Datenbanksystem« 
im Fokus. 

(5.3) Ja, und zwar 

Datenbanksystem D und Datenbanksystem E 

3.2 Fehlererkennung und Fehlerbehandlung 

Als fehlerhafte Eingaben werden die natürlichsprachlichen Benutzereingaben 
bezeichnet, die vom Parser nicht akzeptiert werden oder nicht semantisch interpretiert werden 
können. Dabei können solche Benutzereingaben oftmals syntaktisch korrekt, semantisch bedeu- 
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tungsvoll und fehlerfrei sein. Der Konflikt liegt darin, daß die Benutzereingabe vom System 
nicht verstanden wird, weil natürlichsprachliche Systeme im Wortschatz, in den Sprachfähig- 
keiten und im modellierten Wissen limitiert sind. Die Komponente zur Fehlererkennung und 
Fehlerbehandlung soll die Ursachen, die zu einem Konflikt geführt haben, angeben und dar- 
überhinaus den Benutzer bei der Beseitigung von Konflikten unterstützen. Dabei stellt das Sy- 
stem ihm eine Auswahl von Anfragen zur Verfügung, von denen das System annimmt, daß sie 
der ursprünglichen Absicht des Benutzers gerecht werden können. 

3.2.1 Syntaktische Fehler 

Zwangsläufig ergeben sich häufig deshalb Fehler, weil der Benutzer Wörter in sei- 
ner Anfrage benutzt, die nicht im Lexikon enthalten sind. Eine Anfrage sollte aber auch dann 
bearbeitet werden, wenn ein unbekanntes Wort im Eingabesatz enthalten ist. 

Der Parser von KEYSTONE soll die Fähigkeit besitzen, ein unbekanntes Wort zu 
überspringen und dabei anzugeben, um welche Wortart es sich bei dem unbekannten Wort 
handeln kann. Unter der Prämisse, daß nur Adjektive, Adverbien, Nomen und Verben Wortar- 
ten sind, die nicht vollständig im Lexikon des Systems gespeichert sind, und mit dem Wissen, 
daß gewisse Wortarten bestimmte Endungen besitzen und daß die Eingabe den vom Verb vor- 
gegebenen Satzbauplan entsprechen muß, wird die Menge der Wortarten, denen das unbekann- 
te Wort angehören kann, reduziert. Das Wissen über die Morphologie liegt in der Morpholo- 
giekomponente vor, das Wissen über die Satzbaupläne ist in den Beschreibungen eines Verbes 
im Lexikon enthalten. 

Mit Hilfe des konzeptionellen und des interpretativen Wissens der Wissensbasis 
(vgl. Kap.2.1) erhält man dann Aufschlüsse über mögliche Interpretationen des unbekannten 
Wortes und das System bekommt dadurch die Möglichkeit, dem Benutzer neue Anfragen 
anzubieten, die im gegebenen Kontext für den Benutzer relevant und vom System lösbar sind. 

Bsp.6: Das unbekannte Wort »XYZ« in (6.1) wird an Hand von sprachlichem Wis- 
sen als Nomen klassifiziert. 

( 6.1) Läuft Everyman 4.05 unter XYZ? 

Mit Hilfe der Beschreibung (3.1) aus der Wissensbasis (vgl. Kap. 2.1.) wird die interne Relation 
»runs_under« als geltende Interpretationen für (6.1) ausgewählt. Aus dem konzeptionellen Wis- 
sen der Wissensbasis in (2.1) läßt sich schließen , daß das System die Eingabe (10) bezüglich 
der Relation » runs_under « nur interpretieren kann , wenn es sich bei »XYZ« um irgendein Be- 
triebssystem handelt. Auf (6.1) kann dann eine Reaktion wie in (6.2) angegeben erfolgen. 

( 6.2) XYZ ist dem System nicht bekannt. Vermutlich ist es ein Betriebssystem. 

Wollen Sie wissen 

Unter welchen Betriebssystemen läuft Everyman 4.05? 
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Auf Wortebene werden außerdem Rechtschreibfehler erkannt und durch Sonder- 
zeichen wie »-« und »/« zusammengesetzte Wörter als zwei Teilworte unabhängig voneinan- 
der behandelt, womit überprüft werden kann, ob ein Teilwort bekannt ist. 

Bsp.7 : Eingabesatz (7.1) enthält den unbekannten Begriff »XYZ-Pascal«, wobei 
das Teilwort »Pascal« bekannt ist. 

(7.1) Gibt es einen Compiler für XYZ-Pascal? 

Das System kann gegenüber dem Benutzer kooperativ reagieren, indem es die Informationen 
anbietet, die es Über andere Pascal-Versionen besitzt (7.2). 

(7.2) Das System besitzt keine Informationen über XYZ-Pascal 

Wollen Sie wissen 

Welche Compiler für Pascal gibt es? 

Treten bei einer Eingabe Konflikte auf, die dadurch entstehen, daß mehr als ein 
Wort im Eingabesatz unbekannt ist bzw. daß ein sprachliches Konstrukt benutzt wird, welches 
in der Grammatik des Systems nicht abgebildet ist, dann versucht das System, dem Benutzer 
ein Schlagwortverzeichnis anzubieten. Dabei soll der Benutzer unter den Begriffen, die im Satz 
noch erkannt werden, und dem aktuellen Fokus auswählen können. Zusätzlich soll die Stelle 
der Benutzereingabe angegeben werden, an der das Parse-Verfahren abgebrochen wurde. 

3.2.2 Semantische Fehler 

Als semantisch fehlerhaft wird eine Eingabe dann bezeichnet, wenn die Eingabe 
syntaktisch korrekt ist, aber eine Interpretation in bezug auf das konzeptionelle Wissen des Sy- 
stems nicht gebildet werden kann. 

Bei einer Anfrage nach der Gültigkeit einer Relation zwischen zwei Objekten 
kann der Wertebereich der intern angesprochenen Relation verletzt werden. Als Konfliktlö- 
sung bietet sich unter anderem die Substitution der angegebenen Relation oder eines der bei- 
den Objekte an [4]. In Bsp. 8 wird die Inanspruchnahme der Wissensquellen zur Behandlung 
von semantischen Fehlern verdeutlicht. Dabei wird die interne Interpretation der angegebenen 
Relation durch eine andere systeminterne Relation substituiert. 

Bsp.8: Die Anfrage (8.1) wird wegen des inter pretativen Wissens (3.1) der Wissens- 
basis intern durch » runs_under « repräsentiert. 

(8.1) Läuft die Festplatte des PC-XT mit dem PC-AT02? 

Durch die konzeptionelle Beschreibung (2.1) der Wissensbasis besitzt das System das Wissen, 
daß die in (8.1) angesprochenen Objekte nicht innerhalb des Wertebereichs der Relation 
» runs_under « liegen. Aus dem konzeptionellen Wissen lassen sich jedoch die Relationen 
»connectable _to« und » contains __part« bestimmen , die beide auf die angegebenen Objekte an- 
wendbar sind. Diese Relationen werden in (8.2) als Reaktion auf (8.1) zur Auswahl vorgegeben. 
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(8.2) Festplatte des PC-XT ist ein spezielles Speichermedium. 

PC-AT02 ist ein spezieller PC. 

Das System kennt keinen Zusammenhang »läuft mit« zwischen Festplatte des 

PC-XT und PC-AT02. 

Wollen Sie wissen 

Kann die Festplatte des PC-XT an den PC-AT02 angeschlossen werden? 

oder 

Enthält der PC-AT02 die Festplatte des PC-XT? 

Analog dazu kann die Gültigkeit zwischen einem angegebenen Objekt und zu- 
geordnetem Attribut verletzt werden. Dieser Konflikt kann beispielsweise dadurch gelöst 
werden, indem das Attribut bei der Beantwortung der Anfrage unberücksichtigt bleibt. Diese 
Auslassung wird dem Benutzer jedoch mitgeteilt. In den Fällen, in denen ausschließlich nach 
der Beziehung zwischen Objekt und Attribut gefragt wird, ist dies jedoch nicht möglich. Der 
Benutzer erhält dann in Abhängigkeit vom Fokus zulässige Attribute zum angegebenen Objekt 
bzw. zulässige Objekte zum angegebenen Attribut zur Auswahl. 



Die Behandlung von semantischen Fehlern basiert auf einem Regelsystem, welches 
heuristisch die Reaktion auf einen Fehler in Abhängigkeit vom Fragetyp (ja/nein-Fragen, 
»welch-Fragen« und andere »w-Fragen«), vom Typ des genannten Objekts (Sammelbegriff 
oder Eigenname eines realen Produkts) und vom Fokus bestimmt. Bsp. 9 enthält die Regel für 
die Abarbeitung des Fehlertypus, wie er in Bsp. 8 angegeben wurde. 

Bsp.9: (R9.1) enthält die Regel zur Abarbeitung des Fehlertypus, wie er in Bsp.8 
angegeben wurde. 

(R9.1) Wenn eine Ja/Nein-Frage semantisch nicht interpretierbar ist 

es sich dabei um eine zweistellige Relation handelt 
beide Objekte reale Produkte repräsentieren 

es existiert mindestens eine Relation R, bei der die genannten Objekte 
im Definitionsbereich liegen 

dann bestimme den Sammelbegriff X des ersten Objekts Ol und gebe X aus 

und bestimme den Sammelbegriff Y des zweiten Objekts 02 und gebe Y aus 
und gebe unknown( vom Benutzer angegebene Relation bzgl. ( 01,02)) aus 
und gebe alle Relationen R mit den Objekten Ol, 02 im Menue aus 



und 

und 

und 



Eine Relation kann auch durch die Hintereinanderausführung mehrerer Relationen 
definiert sein. Dadurch können Vorannahmen, die der Benutzer bei einer Anfrage schon im- 
plizit gezogen hat, von der Problemlösekomponente bereits erkannt werden und müssen bei 
der Fehlererkennung nicht mehr berücksichtigt werden. 
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Bsp . 10: Neben (2.1) ist die Relation »runs_under« auch durch (10.1) in der Wis- 
sensbasis definiert . 

( 10.1 ) def _j>seudo_rel( runs _under , 'Programmier spräche' x' Betriebssystem! ) . 

Der Fakt »def _pseudo_rel« deutet auf die Verkettung mehrerer Relationen hin. So läuft eine 
Programmiersprache dann unter einem bestimmten Betriebssystem , wenn es einen Compiler oder 
Interpreter für diese Programmiersprache gibt , der unter dem bestimmten Betriebssystem läuft. 

3.3 Klärungskomponente 

Sobald eine Benutzereingabe mehrdeutig interpretiert werden kann, wird die Klä- 
rungskomponente aktiviert, die an Hand eines Auswahlangebots diese verschiedenen Interpre- 
tationsmöglichkeiten andeutet. Der Benutzer kann dann durch Auswahl aus dem Angebot oder 
durch eine Neuanfrage sein Problem konkretisieren. 

Eine Selektion der Interpretationsmöglichkeiten wird notwendig, um die Informa- 
tionsmenge einzuschränken, die auf eine Benutzeranfrage ausgegeben werden könnte. Der Be- 
nutzer soll sich innerhalb der Informationen, die das System bereitstellt, zurechtfinden können. 

Bsp. 11 

( 11.1) Wie groß ist ein AT? 

Das Wort »groß« in (11.1) kann dahingehend interpretiert werden, daß der Benutzer sich über 
die physikalische Ausdehnung oder über die Speicherkapazität erkundigen will. Bei dem Be- 
griff »AT« handelt es sich um eine Rechner fami lie, die je nach exakter Typenbezeichnung un- 
terschiedliche technische Daten besitzt. Zusätzlich bezieht sich der Begriff »AT« auf eine Kon- 
figuration mehrerer Hardwarekomponenten, wobei einige davon eine physikalische Ausdehnung 
besitzen. Jede Konfiguration enthält je nach Ausrüstung verschiedene Kenndaten über Haupt- 
speicherkapazität und Kapazität der Sekundär Speicher wie Festplatten- und Diskettenlaufwerk. 

Die Klärungskomponente kann zum Selektieren von Interpretationsmöglichkeiten 
den Fokus (vgl. 3.1) hinzuziehen. Der Interpretationsspielraum läßt sich durch den Kontext 
einengen. War bezüglich Bsp. 11 zuvor von der Möglichkeit die Rede, daß die Systemeinheit 
eines AT in einem Ständer senkrecht aufgestellt werden kann, so erscheint für Anfrage (11.1) 
nur eine Interpration »wie groß ist die physikalische Ausdehung des Ständers für die Syste- 
meinheit des AT« sinnvoll. War jedoch zuvor nach der Belegungsgröße einer Anwendungs- 
software gefragt, so ist die Interpretation »wie groß ist der Hauptspeicher des AT« 
naheliegend. 

Weiterhin wird eine Strategie entwickelt, die eine Klärung stufenweise vornimmt, 
um dabei möglichst effizient eine Selektion der Interpretationsmöglichkeiten zu erreichen. So 
erscheint in Bsp 11. die Klärung des Begriffs »groß« vorrangig vor der Klärung des Begriffs 
»AT« zu sein. 




- 49 - 



3.4 Benutzermodellierung 

Kommunikation kann nur dann sinnvoll und kooperativ ablaufen, wenn die Dia- 
logpartner eine Modellvorstellung voneinander haben, die weitgehend dem Dialogpartner 
entspricht. Bei einer wissensbasierten Schnittstelle sollte deshalb eine individuelle Behandlung 
des Benutzers über den Aufbau eines Benutzermodells verwirklicht werden [5]. 

Innerhalb von KEYSTONE sollen die Kenntnisse eines Benutzers bezüglich des 
Umgangs mit dem System modelliert werden. Außerdem sollte aus dem Dialog geschlossen 
werden, ob und welche dem System bekannte Hardware bzw. Software vom Benutzer ange- 
wandt wird. 



Die Kenntnisse des Benutzers über das System werden statistisch an Hand dessen 
Reaktionen in speziellen Systemzuständen auf gezeichnet. Gleichförmige Reaktionen können 
Anzeichen dafür sein, daß der Benutzer alternative Möglichkeiten des Systems in dieser Situa- 
tion nicht kennt und somit auch nicht ausführen kann. Durch unaufgeforderte Hilfe kann das 
System dem Benutzer gezielte Bedienungshinweise geben [6]. Gibt beispielsweise der Benutzer 
im Klärungsdialog eine zur Auswahl gestellte Alternative trotzdem als natürlichsprachliche 
Anfrage ein, dann ist der Hinweis angebracht, daß einfacherweise eine Alternative ausgewählt 
wird, indem die gewünschte Alternative mit dem Cursor angesteuert und daraufhin die 
Return-Taste gedrückt wird. 

Ein wichtiger Aspekt bei der Information über spezielle Hardware- und Software- 
produkte betrifft die Fragestellung, ob das entsprechende Produkt innerhalb der PC- 
Ausstattung des Benutzers einsetzbar ist. Damit der Benutzer seine PC-Ausstattung nicht im- 
mer explizit angeben muß, wird versucht, möglichst aus dem Dialog Wissen über die vorhan- 
dene Ausstattung zu schließen. Vage Annahmen müssen dabei durch konkrete Systemanfragen 
an den Benutzer bestätigt werden, bevor sie im Benutzermodell gespeichert werden. Besitzt das 
Benutzermodell Kenntnis über die PC-Ausstattung des Benutzers, so kann diese im Dialog mit 
verwendet werden. Der Benutzer kann sich etwa durch die Äußerung »mein PC« darauf 
beziehen. Das System kann Antworten dahingehend strukturieren, daß zwischen Produkten, 
die in die PC-Weit des Benutzers integrierfähig sind, und den übrigen Produkten unterschie- 
den werden kann. 

4. Ausblick 

Durch Anreicherung von Wissen über Benutzer und Schnittstelle wird der Zugang 
zu einem Expertensystem erleichert, weil das System in Konfliktfällen Alternativen anbieten 
kann. Dadurch verhält sich das System nicht nur kooperativ sondern es zeigt sich auch 
transparent. Der Benutzer lernt damit, ein Expertensystem zu nutzen und dessen Fähigkeiten 
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besser einzuschätzen. Die oben angesprochenen Komponenten und Strategien befinden sich in 
der Implementierungsphase zum weiteren Prototyp KEYSTONE V. 2.0. 

Ansatzweise existieren schon Modelle, Methoden und Implementationen über wis- 
sensbasierte Schnittstellen und kooperative Systeme, die hauptsächlich aus dem Gebiet der na- 
türlichsprachlichen Auskunftssysteme [7] und des intelligenten computerunterstützten Unter- 
richts kommen [8]. Dennoch befindet sich die Entwicklung erst in den Anfängen. Bislang kön- 
nen viele Fragestellungen, wie etwa nach der Intention eines Benutzers und dem zugrundelie- 
genden Plan, mit dem er seine Absicht verfolgt, aus dem Dialog heraus nicht beantwortet wer- 
den [9]. Probleme beim Einsatz von wissensbasierten Schnittstellen bereitet auch die Selektion 
des Wissens, das dem Benutzer zugänglich gemacht werden soll. Kooperativität zeigt sich eben 
auch darin, daß sich ein System auf die Ausgabe von wesentlichen Informationen beschränken 
kann, damit der Benutzer nicht von einer Informationsflut erdrückt wird. 
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FORK: A System for Object- and Rule-Oriented 

Programming 
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Zusammenfassung. Das Ziel des FORK-Projekts besteht in der Implementierung 
eines primär objekt-orient ierten Wissensreprsentationssystems und seiner Anwendung 
auf den Entwurf und die Fehlerdiagnose technischer Systeme. Während der Kern des 
Repräsentationssystems FORK vollständig objekt-orientiert ist, soll das System als 
Ganzes eine Vielfalt von Programmierstilen unterstützen. Im folgenden beschreiben 
wir eine Erweiterung zur regel-orientierten Programmierung, die die sprachliche Aus- 
druckskraft von FORK über diejenige von LOOPS hinaushebt. Als eine Anwendung 
der regel-orientierten Komponente wurde eine Constraint-Sprache (relations-orienterter 
Programmierstil) implementiert, die ein wichtiges Werkzeug im Rahmen unseres An- 
satzes zum Entwurf und zur Fehlerdiagnose technischer Systeme darstellt. 

Der nächste Schritt im FORK-Projekt schließt die Entwicklung eines allgemeinen 
logischen Rahmensystems ein, wozu eine logische Rekonstruktion objekt-zentrierter Re- 
präsentationen, Zugriff auf komplexe Beschreibungen mittels Unifikation und Deduk- 
tionen über strukturierte Objekte gehören. Das Problem der Nicht-Monotonität wird 
durch einen DeKleers ATMS ähnlichen Modul behandelt werden. Weiterhin erhof- 
fen wir Fortschritte durch einen neuen allgemeinen Ansatz zur Darstellung zeitlicher 
Verhältnisse bei der Modellierung technischer Systeme, was u.E. eines der wichtigsten 
Themen in diesem Bereich ist. 

Abstract. We describe progress made within the FORK project, whose goals are the 
implementation of a primarily object-oriented knowledge representation system and its 
application to the design and fault diagnosis of technical systems. Whereas the kernel 
of the FORK representation system is completely object-oriented, the system as a whole 
is supposed to integrate a variety of different programming styles. In the following, an 
extension for rule-oriented programming is described, which raises the descriptive power 
of the FORK system beyond that of LOOPS. As an application of the rule-oriented 
component, a constraint language has been Implemented which plays an important rule 
in our approach to the design and fault diagnosis of technical systems. 

The next steps in the FORK project will include the development of a general lo- 
gical framework, comprising a logical reconstruction of object-centered representations, 
retrieval of complex descriptions by unification, and deductions on structured objects. 
The problem of non-monotonicity will be dealt with on the meta level by a module 
similar to DeKleer’s ATMS. Further progress shall be achieved by concentrating on a 
general treatment of the problem of time in modelling technical systems which is to our 
opinion one of the most important issues. 
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1 FORK: A Flavor-Based Object-Oriented Know- 
ledge Representation System 

1.1 Knowledge Representation and Object-Oriented Program- 
ming 

Knowledge-based systems differ from other software systems in that they contain an 
explicit encoding of the respective domain knowledge. There are at least two kinds 
of prerequisites for knowledge representation: methodological (i.e. epistemological and 
logical) and technical (in a sense linguistic) ones. In the following we concentrate on 
the second aspect in presenting a knowledge representation framework which is easy to 
use, extensible, and in particular suitable to represent the kinds of knowledge required 
for designing and diagnosing technical systems. 

Under the technical aspect, representing knowledge in a computational system is 
nothing else than a special kind of programming. For programming seen as a lingui- 
stic activity, questions of expressiveness of the programming language and of adequacy 
and suitability of its means with respect to the field (s) of application are of immediate 
importance. Within the last twenty years, a broad variety of knowledge representation 
languages has been proposed ranging from more or less direct derivatives of first-order 
logic to schemata based on cognitive psychology or applied computer science like associa- 
tive networks, production systems, or procedural languages. One of the most advanced 
approaches along this line were Minsky’s [14] frames. Minsky tried to find a synthesis 
between declarative and procedural systems with an emphasis on object-centered re- 
presentations. With a few exceptions, most of these systems were very experimental in 
character and could not achieve wide usage. 

In the meantime in the field of programming languages a new programming “para- 
digm” emerged: the object-oriented style. The ideas of object-oriented programming 
were realized in various ways, either as programming languages in their own right, like 
Smalltalk-80, or as extensions to already existing languages. 

Which are the salient features of the object-oriented programming style? Object- 
oriented systems offer an integrated view of the concepts of abstract data types and 
generic functions (see [17]). The underlying processing model is characterized as a 
system of communicating objects which pass messages among each other. Each object 
has a set of acquaintances, which are denotations of objects it “knows of”, i.e. it 
can send messages to. Messages themselves are also objects; each message contains 
(a reference to) the addressee, (a denotation of) an operation, and — optionally — 
argument objects. Each object has a protocol which is a set of methods; these are the 
procedures or operations contained in messages it can process. The internal state of an 
object — a set of attributes — as well as its internal processing cannot be inspected from 
the outside. An object may be in an active or passive state, and its activities consist 
in sending, receiving, and processing of messages. Processing a message can cause the 
sending of other messages. Furthermore, most object- oriented systems offer means for 
structuring the object world through a class system by accumulating objects with the 
same protocol in one class. There are distinct class objects which generate instance 
objects as the result of processing a particular message ("instantiate”). Classes can 
usually be ordered in generalization hierarchies, along which inheritance relations with 
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respect to their attributes — declarative or procedural, the latter being methods — 
hold. 

So object-oriented systems offer a lot of features which are desirable for the purpose 
of knowledge representation. Even some features like the distinction between classes and 
instances and the inheritance mechanism are introduced in a methodologically cleaner 
and clearer way than in most knowledge representation systems. For these reasons, the 
FORK system [1] has been based on an object-oriented framework. 

Primarily for its flexibility and extensibility LISP was chosen as the host language. 
Its essential advantage is that it does not enforce a particular programming style, but 
instead allows various programming styles based on different processing models, e.g. 
the imperative, functional and object-oriented styles. Because there is no fundamental 
distinction between program and data in LISP, the integration of object-oriented pro- 
gramming is facilitated by employing the dualism between “passive” data and “active” 
procedures. 

One of the best known object-oriented extensions of LISP is the so called Flavor 
system [19], a portable reconstruction of which was the starting point for the FORK 
system. For the Flavor system, there are two kinds of objects: Classes , which are also 
called * Flavors ”, and their instances . Classes represent generic objects; they describe in- 
stances by specifying sets of declarative (variables) and procedural (methods) attributes 
and inheritance relations: 

• local variables: the so called instance variables, 

• class variables: variables, which are owned by the class, but can be referred to by 
its instances; this is an extension to the original Flavor proposal, 

• component classes , which themselves provide variables and methods through in- 
heritance mechanisms, 

• methods: procedures to process messages: the protocol. 

In FORK classes as well as instances are able to process messages: Whereas classes 
can process messages immediately, instances pass messages to their class they have been 
instantiated from. 

With classes, a generalization hierarchy can be built, which is also called the flavor 
graph. By referring to other classes (“superflavors”) within the definition of a new class, 
attributes of the superclasses are inherited. The root of this — in general directed — 
graph is denoted by the most general class VANILLA which owns those methods which 
are valid for all classes. For the construction of the protocol of a new class, inherited 
methods can be combined in predefined ways (for “primary” methods and “before/ after- 
demons”). So, starting from VANILLA successively more specialized object classes can 
be defined with the possibility of multiple inheritance of attributes. 

The Portable Flavor system does not require — in contrast to the original — any 
modifications to the LISP interpreter. The only requirement to the underlying LISP 
system is full functionality of the closure mechanism. Presently versions for InterLISP 
and CommonLISP exist. 
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1.2 FORK as an Extension of Flavors for Knowledge Repre- 
sentation 

Although there is a close resemblance between an object-oriented system like Flavors 
and object-centered knowledge representation languages like Frames, the latter ones 
provide a repertoire of specialized constructs which are particularly useful for know- 
ledge representation. Therefore the Portable Flavor system has been extended with the 
following features to constitute the FORK kernel: 

• A type concept has been introduced such that restricting ranges of values and the 
definition of modalities for attributes like optional or obligatory are possible. 

• FORK automatically supervises structural relations (integrity constraints) over 
whole objects as defined by the user. 

• Set-valued variables are supported such that besides type constraints for their 
elements also cardinality is checked automatically. Special methods to handle sets 
are provided. 

• In addition to instance variables there are also class variables , as mentioned above. 

• FORK has a versatile interface to the inheritance mechanism which allows different 
ways to control and influence inheritance. With respect to the descriptors of 
variables it is possible to differentiate inheritance according to specific roles, to 
refuse inherited attributes, or to transform inherited attributes (e.g. to rename 
variables) . 

• FORK allows the expression of multiple perspectives . 

The following example, defining a class MOVING-OBJECT and a method SPEED for it, may 
illustrate some of these features: 

(DEFFLAVOR MOVING-OBJECT 

(X-POS Y-POS X-SPEED Y-SPEED MASS) 

: gettable-instance-variables 
( : settable-instance-variables 
X-POS Y-POS X-SPEED Y-SPEED) 

( : initable-instance-variables MASS) 

(DEFMETHOD (MOVING-OBJECT SPEED) () 

(sqrt (+ (square X-SPEED) 

(square Y-SPEED)))) 

Now we define a CAR as a particular MOVING-OBJECT: 

(DEFFLAVOR CAR 

(FRAME-NUMBER 
(NO-WHEELS :M0D OBL 

: DEFAULT 4) 
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(AGGREGATES :MOD OBL 

: DEFAULT ’OK) 

(FUEL :MOD OPT 

:RESTR (OME-OF EMPTY FULL) 

: DEFAULT ’FULL) 

(OIL : DEFAULT ’MAX) 

(BATTERY :RESTR (AN ACCU) 

: DEFAULT BAT-45AH) 

(TYRE-PRESSURE :MODE OBL 

: DEFAULT ’HIGH) 

(DRIVER : RES TR (A PERSON) 

: DEFAULT DUMMY)) 

(MOVING-OBJECT) 

(: settable-instance-variables NO-WHEELS AGGREGATES 
FUEL OIL BATTERY TYRE-PRESSURE DRIVER) 

( :gettable-instance-variables FRAME-NUMBER) 

( : init able -instance -variables FRAME-NUMBER) 

(: required-flavors ACCU PERSON) 

(: documentation The flavors ACCU and PERSON should 
also be defined at time of first instantiation)) 

The instance variable FUEL is restricted by ONE-OF to the values EMPTY and FULL, 
which is the default. The variable BATTERY does only accept instances of the class ACCU 
as values. Defining CAR as a subclass of MOVING-OBJECT enables access to MOVING-OB 
JECT’s instance variables (with the aception of MASS) and methods, i.e., in addition to the 
instance variables defined in CAR, each instance of CAR has also the inherited instance va- 
riables X-POS, Y-POS, X-SPEED, Y-SPEED. Furthermore a class variable SELLING-COM 
PANY is defined, which participates with the instance variable OWNER (an instance of 
PERSON) in an integrity constraint. 

Volkswagens are a brand of CARs: 

(DEFFLAVOR VW ; instance variables: 

((CAR-TYPE :RESTR (ONE-OF PASSAT POLO GOLF) 

(OWNER :M0D OBL 

: DEFAULT (SEND-SELF ’GET ’SELLING-COMPANY)) 

(ID :M0D OBL)) 

(CAR) ; superclass 

(: class-variables (SELLING-COMPANY 

: DEFAULT VOLKSWAGEN-AG 
:RESTR (A COMPANY))) 

( : initable-instance-variables CAR-TYPE) 

(: settable-instance-variables OWNER ID) 

( rgettable-instance-variables CAR- TYPE OWNER ID)) 

Now we create an instance of the VW class: 

(SETQ MY-CAR (SEND VW ’CREATE- INSTANCE 
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• (CAR-TYPE POLO 

OWNER BECKSTEIN 

DRIVER TIELEMANN 

ID ERH-E-536 

BATTERY BAT-45AH) )) 

Of course, the implementation of FORK includes tools for debugging, editing, and 
handling objects (e.g. an interface to the file package). 

2 Rule- Oriented Programming in FORK 
2.1 Rulesets, Rules, and Rule Interpreters 

The first extension to the kernel of the FORK system introduces a new kind of methods: 
Besides methods wr jit ten in the traditional procedural or functional style, they can also 
be defined in the form of rule systems. To be precise, a method may be given as a 
forward-chaining, i.e. data-driven production system. In its present form, the rule- 
oriented component of FORK [18] is more powerful then that of LOOPS [4], because it 
offers additional means for conflict resolution and for processing vague information. 

Each method written in the rule-oriented style is a ruleset, which consists of rules 
of the form 

{rule-name} IF premise THEN action {! meta-info} 

Each ruleset has its own rule- interpret er associated with it which executes the ru- 
les under a forward chaining control regime, which in turn may use different control 
structures varying among rulesets for the selection and processing of rules. 

Because rulesets are ordinary methods of objects, they can be inherited (also as 
“before-” and “after-methods”), so that large rulesets can be structured according to 
an object hierarchy. As ordinary methods, rulesets are activated by message passing. 
Since the control structure (meta-knowledge) for processing rules is associated to a 
ruleset, a clear separation between control and domain knowledge can be achieved. 
Each rule interpreter has the following structure: 

1. Preselection of a subset of rules within the ruleset through comparison of rule 
specific scores with a threshold value which is local with respect to the ruleset. 
This mechanism allows prescreening of the ruleset at runtime. 

2. The preselected rules are checked for applicability and then one applicable rule is 
selected. For this phase three control strategies are possible: 

• FIRST or ALL: In this case the ruleset is assumed to be ordered and the 
check for applicability is performed in the given order. With FIRST the first 
applicable rule is selected, with ALL each applicable rule. 

• PRIO : The value calculated by the evaluation of the premise at runtime is 
used to rank the rules, and the one with the highest value is selected. 

The FIRST and ALL modes correspond to D01 and DOALL in LOOPS. With each 
control strategy, rulesets can also be processed iteratively by means of a WHILE 
option. 
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The following method CONTROL for CAR is defined as a ruleset of three rules: 

(DEFRULESET (CAR CONTROL) () ; no local variables 

((C-FUEL ; rule set 

IF (EMPTY FUEL-LEVEL) 

THEN (SIGNAL "no fuel")) 

(C-OIL 

IF (EQ OIL-LEVEL ’MIN) 

THEN (SIGNAL "no oil") 

(SEND ME ’STOP-ENGINE) 

(STOP! ’EMERGENCY-OFF)) 

(C-BATTERY 

IF (LESSP (SEND BATTERY ’VOLTAGE) 6) 

THEN (SIGNAL "low voltage") 

! (: USAGE ONE-SHOT-BANG)) ) 

(:D0C ruleset for controlling ...) 

(-.CHECK-MODE ALL) 

(-.WHILE (ON IGNITION))) 

As soon as this method is activated, the rule C-BATTERY is checked for applica- 
bility only once (ONE-SHOT-BANG) , and never checked again during eventually 
subsequent iterations, i.e. as long as the ignition is turned on. 

In contrast to the FIRST and ALL modes, for PRIO no static order criterion holds. 
Instead the ordering of rules is determined dynamically by priorities which are 
determined by the rule premises. To achieve that, first of all a transition from 
qualities to quantities has to be made by which a measure of evidence (Certainty 
Factors CF) is determined from the values of premises: 



(not NIL) k (not (NUMBERP X)) 


— > CF 


:= MAXCF 


X = NIL 


--> CF 


:= 0 


(NUMBERP X) 


— > CF 


:= X 



with CF € [OjMAXCF] C N 0 . 

Boolean combinations of premises are calculated by special methods ($AND , $0R, 
$N0T). 

The priority calculated in this way is used to schedule the respective rule in a 
multilevel agenda, from which afterwards the first rule from the level with highest 
priority is selected. 

3. After selection, the action part of the respective rule is executed by the rule 
interpreter. The working memory (context) within the execution is performed is 
the FORK object to which the ruleset method belongs. 

It should be noted that using the PRIO control strategy MYCIN-like rules can be expres- 
sed imediately with FORK’s rule formalism. 
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2.2 Implementation of the Rule-Oriented Component 

For the implementation of rulesets and rules, the kernel language of FORK has been 
used as a metalanguage, i.e., the whole rule component of FORK itself is expressed 
by means provided by the FORK kernel. Rulesets as well as rules are represented 
as FORK objects with appropriate methods. Rulesets are instances of a class RULESET 
which includes parameters and local variables as static components (instance variables), 
methods with defaults for conflict resolution and control- and meta-information (the 
rule interpreter) as dynamic attributes and rules as component flavors. In the same 
way rules are instances of a class RULE with appropriate methods. The programming 
environment of FORK has been augmented for rule-oriented programming with methods 
for debugging, editing, and handling rulesets, and rules which interface to particular 
attributes of the RULESET and RULE classes. 

2.3 A Rule-Based Implementation of a Constraint Language 

To demonstrate the versatility of rule-oriented programming in FORK, it has been used 
to implement a constraint language (after [16]. Constraint languages are a tool for 
relation-oriented programming and, therefore, play an important role in our approach 
to the diagnosis problem (see section 3). What a constraint language has at least to offer 
are means to represent objects which express elementary relations (“constraints”) and 
connections between these objects. So, e.g. a constraint representing an ADDER has two 
input connectors A and B and an output connector S such that the following relations 
hold: S = A + B, and, at the same time B = S - A and A = S - B. Connecting objects 
of this kind leads to the construction of constraint networks in which computations are 
performed by propagation of values. In constraint languages, the term propagation 
covers local computations satisfying local dependences (as expressed by the equations 
for ADDER) as well as spreading values through connectors within a network. 1 In general, 
there is no preferred direction for spreading values. 

So a minimal constraint language has at least to provide constructs to express 

• definitions of constraints, 

• construction of constraint networks, 

• integration of new constraints into an already existing network, 

• communication with the network interface (input and output). 

With FORK, there is a straightforward approach to implement that by expressing 
constraints and connectors as objects and networks as aggregates of those. The propa- 
gation of values, which is locally restricted, is specified by rules belonging to constraint 
objects. For the case of electronic circuits, there are prototypic building blocks, like 
ADDER, of which instances are generated, which in turn are then combined to descrip- 
tions of network by attaching their connectors with each other. As a benefit of the 
object-oriented representation, such a description of a complex network is nothing else 
than one object on a higher descriptive level. 

The following piece of code defines an ADDER: 

1 Spreadsheet programs cure a special kind of constraint systems. 
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(DEFCONSTRAINT ADDER (Al A2 SUM) 

NIL ; local variables 

(A1-A2 ; rule set 

IF (ALL-KNOWN? Al A2) 

THEN (SET-VALUE! SUM 

(PLUS (GET-VALUE! Al) 
(GET-VALUE! A2)) 

*ME)) 

(Al-SUM 

IF (ALL-KNOWN? Al SUM) 

THEN (SET-VALUE! A2 

(DIFFERENCE (GET-VALUE! SUM) 
(GET- VALUE! Al)) 

&ME)) 

(A2-SUM 

IF (ALL-KNOWN? A2 SUM) 

THEN (SET-VALUE! A2 

(DIFFERENCE (GET-VALUE! SUM) 
(GET-VALUE! A2)) 

&ME))) 



A constraint network then can easily be constructed in the following way: 
(DE CONSTRAINT-NET () 



(SETQ A (MAKE-CONNECTOR)) ; generate new instances of 
(SETQ B (MAKE-CONNECTOR)) ; CONNECTOR 

(LET ((X (MAKE-CONNECTOR)) 

. . . ) ; now generate new instances of 

... ; constraint ADDER 

(MAKE-CONSTRAINT ’ADDER ’Al A ’A2 B ’SUM X) 

... )) 



3 Future Work 

In parallel to the implementation of the FORK system, a first study in the field of dia- 
gnosis has been conducted, aiming at a clarification of the basic problems and represen- 
tational needs (cf. [3,13,10]). After considering more traditional rule-based approaches 
to the diagnosis problem, we concentrated on an approach known as “based on structure 
and behavior” (cf. [6,9]). Starting with an algorithm to diagnose multiple failures in 
electronic circuits, considerable extensions had to be made for the more complicated 
case of electromechanical systems. The kernel of the resulting diagnosis system, DIAG- 
TECH, has been implemented in the object-oriented style. In fact, DIAGTECH is a 
hybrid system, because it also supports the rule-based style of diagnosis, for which our 
logic-based “expert system shell” DUCKITO [12] is used as a subsystem. 
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In DIAGTECH, the treatment of conflicts, or inconsistency, as well as particular 
diagnostic heuristics, were embedded into one algorithm. To guarantee the usefulness 
of the chosen approach in the long run, it has to be generalized in a way that the 
recording and processing of inconsistency is performed by a separate general module. 
Indeed, as DeKleer [7] points out, most problem solvers search; if otherwise, a direct 
algorithm would solve the task. Then, two important problems are to be solved, namely, 
how the spaces of alternatives can be searched efficiently, and how the problem solver 
should be organized in general. DeKleer’s solution is convincing: On the one hand it 
is a consequent continuation of the “Truth Maintenance Systems” (TMS) line, which 
forces a clean division within a problem solver between a module solely concerned with 
rules of the domain and another module concerned with recording the current state 
of the search. While the first module draws inferences, the second, the TMS, records 
inferences (“justifications”). So, the TMS serves three roles: 

1. It serves as a “cache memory” for all inferences in that inferences, once made, 
need not be repeated. Inconsistencies, once detected, are avoided in the future. 

2. It allows the problem solver to draw non-monotonic inferences. If non-monotonic 
justifications are present, the TMS has to use a constraint satisfation procedure 
to determine what data are assumed to be valid. 

3. It assures that the data base is contradiction-free. The procedure of dependency- 
directed backtracking identifies and adds justifications to remove inconsistencies. 

DeKleer’s ATMS (Assumption Based TMS) [7] is a very efficient TMS module. In 
particular from our experience with DIAGTECH, but also from general considerati- 
ons about a logical extension to our object-oriented representation system, we decided 
to realize such a module within our framework as the next step of the FORK pro- 
ject. We believe this will be a mandatory prerequisite to address the perspective of 
logic programming, namely (predominantly descriptive) representation and processing 
of relations (constraints) and implications in the object domain, and, in particular, the 
representation and treatment of time in a more general way. The gap between a logical 
reconstruction of object-centered representations (cf. [15,11]) and logic-based represen- 
tation systems with their inferential properties is still to be closed. Retrieval of complex 
descriptions requires a powerful extension to the well-known unifcation algorithms. The 
direction of this research is also influenced by our previous experience with DUCKITO, 
which contains a truth maintenance module and an explanation component on the basis 
of data dependences. 

As far as the problem of representing time and temporal relations is concerned, we 
are currently investigating approaches which reach beyond the one used within DIAG- 
TECH. The latter one has been constructed in the spirit of Doyle’s [8] JACK system. 
The main problem we encountered with it is not a lack of expressive power, but a fun- 
damental discrepancy between constraint-based representations on the one hand and 
the directionality introduced by temporal expressions on the other. Constraint systems 
assume simultaneous propagation of values in all possible directions of a constraint net- 
work, i.e. non-directionality of components and multiple values. A temporal order does 
not allow to consider all “possible worlds” at once, but enforces an order on propaga- 
tion. We hope to find a synthesis of the advantages of both by means of a modal logic 
approach. 
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F ramebasierte Wissensrepräsentation 
mit Hilfe 

objektorientierter Programmierung 
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Zusammenfassung 

Seit der zusammenfassenden Darstellung Minskys (14) ist eine Vielzahl von Systemen 
entstanden, die Wissen in Form von Frames repräsentieren. Dabei ist oft unklar, wel- 
che Rolle Vererbung, Defaultverhalten und andere mit Frames verbundene Prozesse 
spielen. 

ObjTalk ist ein Sprachsystem, in dem Frames als Klassen und Instanzen einer objekt- 
orientierten Sprache realisiert sind. Prozesse sind Reaktionen auf Nachrichten, deren 
Bedeutung auf die Definition von Slots und Methoden zurückgeführt wird. 

Anhand eines Beispiels aus dem Bereich der formularorientierten Finanzplanung wer- 
den Eigenschaften von Obj Talk-Frames illustriert. 
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1. Einleitung 

Seit der zusammenfassenden Darstellung Minskys (14) ist eine Vielzahl von Systemen 
entstanden, die Wissen in Form von Frames repräsentieren. Motiviert waren Frames 
durch die Erkenntnis, daß Menschen einmal Gesehenes oder Erlebtes verwenden, um 
neue Situationen, Ereignisse oder Objekte zu erkennen. Wenn sich Menschen einer 
neuen Situationen gegenübersehen, wählen sie eine Datenstruktur (ein Frame) aus dem 
Gedächtnis aus, das der Situation möglichst nahekommt. Die im Detail abweichenden 
Informationen werden angepaßt. Im ausgewählten Frame sind viele Details bereits 
dargestellt und müssen nicht erneut interpretiert werden. Daher sind Erkennungspro- 
zesse sehr effizient. Sie sind umso effizienter, je besser das ausgewählte Frame der Si- 
tuation entspricht. Die mit Frames verbundenen Mechanismen erlauben einen Frame- 
wechsel, falls ein anderes Frame der Situation besser entspricht. 

Mit Hilfe der “Frametheorie” können viele kognitive Phänomene erklärt werden, z.B. 
das visuelle Erkennen von Gegenständen, Verstehen natürlicher Sprache, Lernen und 
andere grundlegende kognitive Fähigkeiten des Menschen. 

In der Künstlichen-Intelligenz Forschung steht die Wissensrepräsentation mittels 
Frames im Gegensatz zu formalen Ansätzen wie etwa der Logik. In Frames gibt es 
wenig allgemein anwendbare Mechanismen (wie z.B. eine mächtige Inferenzmaschine), 
auf Grund deren kognitive Leistungen erzielt werden. Diese hängen vielmehr von der 
konkreten Situation ab und können für unterschiedliche Situationen sehr verschieden 
sein. 

Ein wesentliches Merkmal von Frames besteht im Vorhandensein von Strukturen, die 
es erlauben, Situationen, Ereignisse und Objekte prototypisch zu repräsentieren. 
Minsky hat die dafür notwendigen grundlegenden Mechanismen wie Defaults , 
Framesysteme und Framenetze beschrieben. Er hat jedoch keine konkreten Hinweise 
gegeben, wie diese in Software-Systemen zu realisieren sind. Es sind daher eine Reihe 
framebasierter Systeme entstanden, die Aspekte der “Frametheorie” unterschiedlich 
implementieren. 



In den folgenden Abschnitten wird auf die grundlegenden Eigenschaften von Frames 
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eingegangen. Anhand eines Beispielsystems, das Frames zur Repräsentation von Wis-' 
sen aus dem Bereich der Projektfinanzierung benutzt, werden die Eigenschaften von 
Frames konkretisiert. Es wird ein Sprachsystem - ObjTalk - vorgestellt, daß die Me- 
chanismen der Frames objektorientiert realisiert. 

2. Frames 

Ein Frame ist eine Datenstruktur, mit der prototypische Situationen, Ereignisse und 
Gegenstände dar gestellt werden. Wenn man sich einer neuen Situation gegenübersieht 
oder die Betrachtungsweise eines Problems grundlegend ändert, wählt man aus dem 
Gedächtnis eine Struktur aus, die der neuen Situation möglichst nahekommt. Eine 
solche Datenstruktur ist ein Frame. Das Aussehen eines Zimmers oder der Verlauf ei- 
nes Kindergeburtstages (vgl. (14)) sind Situationen und Ereignisse, die in Frames dar- 
gestellt werden können. In Computersystemen, die Kommunikation mit Menschen un- 
terstützen, werden Situationen, Ereignisse und Objekte des Dialogs als Frames reprä- 
sentiert. In solchen Dialogen sind die Dialoghistorie, Benutzerprofile und Kommunika- 
tionsobjekte wie Formulare, Menüs und Piktogramme als Frames dargestellt. 

Abbildung 2-1 zeigt eine Reihe von Formularen und Piktogrammen, die zu FINANZ 
(16) gehören. FINANZ ist ein System, das den Benutzer bei der Erstellungen von Fi- 
nanzierungsplänen für Forschungsprojekte unterstützt. Die Frames des Systems re- 
präsentieren sichtbare Objekte (Formulare, Formularfelder, Piktogramme) und inter- 
nes Wissen über angemessene Werte und Beziehungen zwischen den Inhalten von For- 
mularfeldern. FINANZ-Frames stellen dabei prototyp isch das Wissen aus dem Bereich 
formularorientierter Finanzplanung dar. 

Mit den Frames sind Informationen verbunden, auf welche Ereignisse man sich einzu- 
stellen hat, was man als nächstes in einer Situation erwarten kann, aber auch was man 
zu tun hat, wenn diese Erwartungen nicht erfüllt werden. Frames etablieren also den 
“Rahmen”, innerhalb dessen* Informationen interpretiert werden. Beim Ausfüllen ei- 
nes Formularfeldes, in dem ein Datum erwartet wird, wird diese Erwartungshaltung 
zur Interpretation der Benutzereingabe ausgenutzt (Abb. 2-2). 



Terminale. Man kann sich ein Frame als ein Netz aus Knoten und Beziehungen vor- 
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Ein mit FINANZ erstelltes System zum Ausflillen von Finanzierungsplänen für einen 
Projektantrag beim Bundesministerium für Forschung und Technologie. 

Abbildung 2-1: Finanzierungspläne für ein Projekt 
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Beim Ausfüllen eines Datumfeldes wird die Eingabe als Datum analysiert und mit 
plausiblen Werten ergänzt. Auf Grund des Wissens über die Funktion eines Feldes 
kann entschieden werden, welche Eingaben möglich und sinnvoll sind. Erwartungen 
über Benutzereingaben erleichtern die Analyse. 

Abbildung 2-2: Interpretation und Ergänzung von Benutzereingaben 



stellen. Die oberen Ebenen eines Frames sind festgelegt und treffen in der angenom- 
menen Situation immer zu. Die unteren Ebenen haben viele Enden ( Terminale , 
Slots), die erst in konkreten Situationen mit Daten gefüllt werden. Terminale tragen 
Bedingungen, die diese Daten erfüllen müssen. Eine der Bedingungen kann lauten, 





- 68 - 



daß ein Terminal nur mit einem bestimmten Frametyp belegt werden darf. Komple- 
xere Bedingungen sind in Form von Relationen beschrieben, die zwischen den Termi- 
nalen des F rames gelten. 

Die Interpretation eines Feldinhalts als Datum wird durch eine entsprechende Restrik- 
tion am Datumslots des Zeitraumframes bewirkt. Frames, die Formularfelder be- 
schreiben, haben Slots für Position, Größe, den verwendeten Zeichensatz und das um- 
gebende Formular. Diese Slots können nur mit Punktframes, Größenframes, Zeichen- 
satzframes und Formularframes belegt werden. Zwischen Zeichensatz, Zeilenabstand 
und Feldgröße besteht ein Zusammenhang, der als Relation zwischen den entsprechen- 
den Slots ausgedrückt wird. 

Framesysteme. Frames, die sich auf gemeinsame Teilaspekte beziehen, sind in 
Framesystemen zusammengeschlossen. Transformationen zwischen Frames werden 
ausgenutzt, um Berechnungen wie das Erkennen von Gegenständen ökonomischer zu 
gestalten oder Änderungen von Betonung und Aufmerksamkeit zu repräsentieren. 

In FINANZ können Formulare unter verschiedenen Perspektiven gesehen werden. Für 
den Sachbearbeiter stehen andere Informationen im Vordergrund als für den Antrag- 
steller. Beide Sichtweisen sind durch Frames repräsentiert, deren Informationsgehalt 
sich teilweise überlappt. Die Verschiebung der Perspektive wird durch den Übergang 
zwischen den Formulartypen dargestellt. Die Werte bestimmter Slots bleiben dabei 
erhalten. Das Personalposten-Formular aus Abbildung 2-1 zeigt Daten, die in den an- 
deren beiden Formularen dargestellt sind, unter einer modifizierten Perspektive. 

Defaults. In Frames werden neben Erwartungen auch Annahmen dargestellt. Dazu 
sind die Slots eines Frames mit Defaults gefüllt, d.h. mit Werten, die für eine gegebe- 
ne Situation typischerweise gelten. Defaults sind nur lose mit den Terminalen ver- 
bunden. Sie können in einer konkreten Situation modifiziert oder ersetzt werden. So 
können F rames viele Details tragen, ohne die Situationen, Ereignisse oder Objekte ein- 
zuschränken. Inwieweit eine Modifikation oder Ersetzung der Defaultwerte möglich 
ist, hängt von den Eigenschaften des Frames selbst ab, wie z.B. von den mit den Ter- 
minalen verknüpften Bedingungen. 
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Mit der Aktivierung eines Formulars werden viele Voreinstellungen wirksam. Anzahl, 
Größe und Anordnung der Felder sind vorgegeben, können aber im Einzelfall abgeän- 
dert werden. Felder, die zu einer Summe beitragen, sind mit dem Wert 0 vorbesetzt. 
Diese Defaults ermöglichen die Repräsentation von Standardfällen. Sie entbinden den 
Benutzer von der Notwendigkeit, alle Einzelheiten einer Anwendung im Voraus festle- 
gen zu müssen. 

Spezialisiertes Wissen. In Frames ist das Wissen situations- oder bereichsspezifisch 
repräsentiert. In FINANZ kommt das Wissen über Finanzplanung zum Ausdruck, 
wenn der Benutzer Feldwerte in den Formularen ändert (Abb. 2-3). 
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Nach Modifikation der Anzahl der Mitarbeiter der Gehaltsstufe Bat Ia von 2 auf 3 
werden Jahresausgaben und Endsummen beider Formulare automatisch angepaßt. 

Abbildung 2-3: Das Fortpflanzen von Veränderungen 



Abhängigkeiten zwischen Formularfeldern sind dabei nicht auf arithmetische Bezie- 
hungen beschränkt. In der Projektplanung muß die Qualifikation von Mitarbeitern 
und die Aufgabenstruktur des Projekts in einer bestimmten Beziehung zueinander ste- 
hen. Auch solche Beziehungen können in Frames repräsentiert werden. 

Kontextabhängiges Wissen. Die Aktivierung von Frames eines Framesystems eta- 
bliert einen Kontext, innerhalb dessen Benutzerähßerungen interpretiert werden. Die- 
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ser Kontext umfaßt alle für die augenblickliche Situation relevanten Informationen. 
So können z.B. Hilfetexte der Dialogsituation angepaßt werden (Abb. 2-4). 
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Erklärende Information über den Zweck eines Feldes kann angefordert werden. Sie 
wird in eigenen Fenstern dargestellt. 

Abbildung 2-4: Statische Hilfen 



Framebasierte Dialoge. In framebasierten Dialogen werden die Aktionen des Sy- 
stems und die Interpretation der Benutzereingaben von den Eigenschaften der aktiven 
Frames bestimmt (1). Der Dialogverlauf wird in eigenen Frames repräsentiert. Diese 
dienen als Referenz für Benutzeranfragen, die sich auf Ereignisse in der Dialogge- 
schichte beziehen. Sie werden z.B. herangezogen, wenn das System Teile des augen- 
blicklichen Zustands erklären soll (Abb. 2-5). 

Elemente der Frametheorie Finden in verschiedener Form Eingang in Wissensrepräsen- 
tationssprachen. FRL 1 (20) war einer der ersten Versuche, Systemverhalten mit Hilfe 
von Frames zu beschreiben. Frames wurden dabei in einer Generalisationshierarchie 
angeordnet, in der sich Eigenschaften von allgemeinen auf spezielle Frames vererben. 
Der Begriff der Vererbung spielt seit dem eine charakterisierende Rolle für framebasier- 
te Systeme. 
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Der Benutzer hat nach der Berechnung der Personalausgaben für die Gehaltsklasse 
Bat Ia gefragt. Dazu wurde vom System eine Erklärung ausgegeben, die auf Grund 
der Benutzereingaben und der Beziehungen zwischen den Feldern generiert wurde. 

Abbildung 2-5: Dynamische Hilfen 



In den meisten framebasierten Systemen werden Frames als passive Datenstrukturen 
gesehen, die in ein umfassenderes Sprachsystem eingebettet sind: 

• In FRL sind Frames Record- ähnliche LISP-Datenstrukturen, für die allge- 
meine Zugriffsfunktionen definiert sind. 

• In KRL werden angebundene Prozeduren eingefiihrt, um Frames mit pro- 
zeduralen Eigenschaften auszustatten. 

• In jüngerer Zeit werden Aspekte der regelorientierten Programmierung 
(z.B. in LOOPS (2) und KEE 3 ) mit einer framebasierten Sprache 4 verbun- 



2 

Knowledge Representation Language (3) 

3 

Knowledge Engineering Environment (12) 

4 In beiden Fällen handelt es sich um UNITS (23). 
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den. 

• In LOOPS werden Frames als Objekte verstanden, denen Nachrichten ge- 
sandt werden können. Damit werden Eigenschaften objektorientierter Pro- 
grammierung mit Frames verbunden. 

• In Expertensystemumgebungen wie KEE, ART 5 und Babylon (7, 8) werden 
Elemente logikorientierter Programmierung mit Frames verbunden. 

Framebasierte Systeme scheinen mit Frames alleine nicht auszukommen. Oft werden 
Frames nur in ihrer Eigenschaft als Datenstrukturen mit Vererbung gesehen, und die 
übrigen Aspekte der Frametheorie, insbesondere Prozesse wie das Aufbauen von Er- 
wartungen, der Wechsel zwischen Frames, die Darstellung von Unterschieden und 
Ähnlichkeiten und das Defaultverhalten werden in Mechanismen dargestellt, die mit 
Frames zunächst nichts zu tun haben. 

Diese Unzulänglichkeiten Finden ihren Ausdruck in der anhaltenden Auseinanderset- 
zung um die Semantik von Frames und wie Frames repräsentiert werden sollen. Es 
werden grundlegende Fragen nach der Bedeutung von Slots (24) und von Vererbung 
(6) gestellt, und ob Frames nicht grundsätzlich als eine Menge logischer Prädikate auf- 
gefaßt werden können (11). 

In den folgenden Abschnitten stellen wir ObjTalk (19, 17, 18) als eine objektorientier- 
te Sprache vor, die es erlaubt, die mit Frames verbundenen Prozesse objektorientiert 
zu repräsentieren. 

3. ObjTalk 

In der objektorientierten Betrachtungsweise von ObjTalk werden Frames als Objekte 
realisiert, deren Eigenschaften mit dem Verhalten beim Empfangen von Nachrichten 
beschrieben werden. In den folgenden Abschnitten werden wir kurz auf die Prinzipien 
objektorientierter Programmierung eingehen. Anschließend werden die Erweiterungen 
beschrieben, die es erlauben, ObjTalk als Framesprache zu verwenden. 



Automated Reasoning Tool 
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3.1. Objektorientierte Programmierung 

Objektorientierte Programmierung unterscheidet sich von der herkömmlichen Art der 
Programmierung dadurch, daß nicht mehr der Programmier schritt oder die 
Programmieranweisung sondern das Objekt im Mittelpunkt steht. Die Kontrolle in ei- 
nem Programm wird nicht mehr durch Kontrollstrukturen wie Schleife , Verzweigung , 
Sprung , usw. sondern durch das Versenden und Empfangen von Nachrichten be- 
schrieben (Abb. 3-1). 




Abbildung 3-1: Einige der Nachrichten, die an ein Fensterobjekt gesandt werden 

können, erscheinen als Einträge des Fenstermenüs 



Nachrichten werden auf Grund der Methoden und des internen Zustands eines Ob- 
jekts interpretiert. Der interne Zustand eines Objektes ist durch die Werte seiner 
Slots beschrieben (Abb. 3-2). 

Die Reaktion auf eine Nachricht kann in der Veränderung des Objekt zustands beste- 
hen (ein Fenster ändert seine Position auf dem Bildschirm), in der Rückgabe einer 
Antwort (eine Fenster antwortet mit seiner Größe) oder im Senden weiterer Nachrich- 
ten (eine Fenster sendet eine Nachricht an sein assoziiertes Menüobjekt). Objekt und 
Nachrichten bilden eine Einheit, so daß Objekte nur ihren eigenen Zustand unmittel- 
bar verändern können und sie nur Nachrichten an Objekte senden können, die ihnen 
bekannt sind. Objekte haben also ein Außen und ein Innen . Nach außen sind die 
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Ein Fensterobjekt besitzt Slots für den Bereich des Bildschirms, den es einnimmt, für 

ft 

ein Menüobjekt mit Fensteroperationen, für das Muster des Hintergrunds, für Rän- 
der, für Titelzeile und für den aktuellen Zeichensatz. 

Abbildung 3-2s Der interne Zustand eines Fensterobjekts 



Nachrichten bekannt, auf die das Objekt reagieren kann. Im Inneren kennt das Ob- 
jekt seine Methoden und seinen internen Zustand. Auf diese Weise kommt ein hohes 
Maß an Modularität und Sicherheit im Bezug auf Seiteneffekte zustande. 

Objekte, die auf Nachrichten ähnlich reagieren (d.h. dieselben Methoden besitzen), 
können zu einer Klasse zusammengefaßt werden. Methoden und die Beschreibung des 
internen Zusatands sind bei der Klasse lokalisiert. So gehört ein bestimmtes Fenster 
zu der Klasse aller Fenster. In objektorientierten Systemen ist darüberhinaus meist 
eine Subklassenbildung möglich. Man spricht von Vererbung von Eigenschaften, wenn 
man ausdrücken will, daß die Reaktion auf Nachrichten und die Beschreibung des in- 
ternen Zustands eines Objekts durch alle Klassen beschrieben werden, in der die Klas- 
se des Objekts enthalten ist. Klassen formen eine Hierarchie, entlang der Eigenschaf- 
ten vererbt werden (Abb. 3-3). 



6 



Objektnamen werden durch #. gekennzeichnet. 
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Die oberen Klassen der Hierarchie beschreiben grundlegende Eigenschaften von recht- 
eckigen Bereichen auf einem “Bitmap-Terminal”. Dort sind Methoden zum Erzeugen, 
Bewegen und Verändern der Größe definiert. In Subklassen kommen neue Eigenschaf- 

y 

ten hinzu oder es werden vorhandene erweitert. 

Abbildung 3-3: Die Klassen eines Fenstersystems 



In unserem Beispiel wird zur Klasse der Fenster (simple-window) eine Subklasse ge- 
bildet, die das Verhalten von Fenstern mit Unterfenster beschreibt (super-window). 
Die Eigenschaften aller Fenster (Position, Größe, die Reaktion auf Nachrichten wie 
aendere-groesse, bewege, usw.) vererbt sich dabei auf die neue Klasse und braucht 
dort nicht wiederholt angegeben werden. Neue Nachrichten wie 

loesche-unterf enster werden in der neuen Klasse zusätzlich definiert. 



7 



Diese Hierarchie ist Teil eines operationalen Fenstersystems (9). 
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3.2. Klassen und Instanzen 

In ObjTalk sind prototypische Sachverhalte, Situationen, Ereignisse und Gegenstände 
- also Frames - in Form von Klassen und Instanzen realisiert. Klassen werden durch 
Methoden , Slots , Superklassen , Regeln und Constraints beschrieben: 

• Deklarative und prozedurale Eigenschaften von Frames werden auf das 
Verhalten beim Empfang von Nachrichten und damit auf die Definition 
von Methoden zurückgeführt (Abschn. 3.3). 

• Slots entsprechen den Terminalen der Frames. In Slotbeschreibungen wer- 
den Werte eingeschränkt oder mit Defaults versehen (Abschn. 3.4). 

• In Klassen werden explizit nur die Eigenschaften beschrieben, die die 
Eigenschaften anderer Klassen, der Superklassen , spezialisieren. Eigen- 
schaften werden von Superklassen ererbt (Abschn. 3.5). 

• Regeln beschreiben, wie Objektzustände, die durch die Wertebelegung von 
Slots repräsentiert sind, in neue Objektzustände Ubergeführt werden 
(Abschn. 3.6). 

• Constraints sind Bedingungen, die zwischen den Slotwetten eines Objekts 
aufrecht erhalten werden. Mit ihnen werden Abhängigkeiten zwischen 
Slots beschrieben (Abschn. 3.7). 

3.3. Methoden und Nachrichten 

In ObjTalk werden die mit Frames verbundenen Prozesse durch Senden und Empfan- 
gen von Nachrichten beschrieben. Der Prozeß des Nachrichtensendens spielt dabei die 
Rolle einer Aufgabendelegation. Wie in einem "System kommunizierender Experten" 
(15) ist das Wissen über verschiedene Problembereiche in verschiedenen Objekten lo- 
kalisiert, die als Experten fungieren. Jedes Objekt hat eine spezielle Expertise, die von 
anderen Objekten Uber das Senden von Nachrichten angefordert werden kann. 

Die Experten überschauen jeweils nur begrenzte Problembereiche. Sie können aber 
Teilprobleme an andere Experten delegieren. Die für das Teilproblem notwendigen 
Daten werden über Slotinhalte mitgeteilt (Abschn. 3.4). 

Zur Darstellung der Abhängigkeiten in FINANZ werden ein Reihe von F rames definiert, 
die Wissensfragmente repräsentieren. Sie stellen z.B. Einflußfaktoren auf das Gehalt 
eines Wissenschaftlers dar. In ihnen ist Wissen über jährliche Steigerungsraten, Ur- 
laubsgeld, Sozialabgaben usw. enthalten. Zusammen formen sie ein Geflecht, dessen 
Teile über Nachrichten aktiviert werden. 
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Für die Interpretation einer Benutzereingabe wird an das Frame, das das betreffende 
Formularfeld repräsentiert, eine Nachricht gesandt. Je nach erwarteter Benutzerein- 
gabe, die durch Frametyp, Restriktionen der Terminalwerte und Relationen zwischen 
den Terminalwerten bestimmt wird, wird die geeignete Interpretationsmethode akti- 
viert (Abb. 2-2). 

Alle Objekteigenschaften werden auf Verhalten und damit auf die Definition von 
Methoden zurückgeführt. 8 Für die objektorientierte Betrachtungsweise, in der Metho- 
den eng mit Frames verbunden sind, spricht die enge Verknüpfung der Prozesse mit 
F rames: 

• Ähnlichkeiten und Unterschiede, sowie Prozesse, die zur Angleichung eines 
Frames führen, hängen in hohem Maße von der Situation, dem Ereignis 
oder dem Gegenstand ab, der durch das Frame beschrieben wird. 

• Kriterien für die Angemessenheit eines Frames zur Beschreibung einer Si- 
tuationen können nicht allgemeiner Natur sein, sondern hängen unmittel- 
bar von dem jeweiligen Frame selbst ab. 

• Prozesse, die bei der Belegung mit Terminalwerten ausgelöst werden, hän- 
gen von den Terminalen des Frames und damit vom Frame selbst ab. 

• Der Übergang zwischen Frames eines Framesystems hängt von den Frames 
ab. Es kommt auf die jeweilige Situation an, was als Veränderung des 
Blickwinkels interpretiert werden kann. 

3.4. Slotbeschreibungen 

Den Terminalen von Frames entsprechen in ObjTalk die Slots von Objekten. Dekla- 
rative Frameeigenschaften wie Restriktionen und Defaultwerte werden mit Hilfe von 
Slotbeschreibungen ausgedrückt. Diese legen darüberhinaus Initialisierungen , 
angebundene Prozeduren und Koreferenzen fest. 

Slotbeschreibungen werden auf die Definition von Slotmethoden zurückgeführt. Diese 
steuern Initialisierungs- und Defaultverhalten und überwachen Slotrestriktionen. Die 
Definition von Slotmethoden auf Grund deklarativer Slotbeschreibungen ist ein we- 
sentliches Prinzip der Obj Talk-Erweiterungen. 



8 



Dies gilt auch für die deklarativen Anteile (Abschn. 3.4). 
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Restriktionen. Restriktionen sind in ObjTalk einstellige LISP-Prädikate oder speziel- 
le Obj Talk-Formen, die den Wert eines Slots auf die Instanz einer Klasse beschränken. 
Restriktionen können durch Und- und Oder-Beziehungen miteinander verknüpft wer- 
den. 

Die Angabe von Restriktionen für einen Slotwert führt je nach Frametyp zur Erzeu- 
gung von Methoden, die das Verhalten des Frames insgesamt steuern. Die Restriktion 
eines Slots auf DM-Beträge einer bestimmten Größenordnung erlaubt die Generierung 
eines Parsers, der beim Belegen des Slots über eine Slotnachricht aktiviert wird. 

Defaults. Defaults sind Formen, die nur dann als Slotwert eingesetzt werden, wenn 
bei Erzeugung einer Instanz kein anderer Slotwert angegeben wird. Bei Instantiierung 
einer Klasse erhält das neue Objekt für jeden Slot eine Initialisierungsnachricht. Dies 
führt dazu, daß das Objekt versucht, den betreffenden Slot mit einem Wert zu bele- 
gen. Dieser Prozeß hängt von den Eigenschaften des Objekts ab. Wird kein Wert zur 
Verfügung gestellt, greift das Objekt auf den Defaultwert zurück. 

Das Initialisierungsverhalten von Slots wird in eigenen Slotmethoden dargestellt, die 
vom Obj Talk-System - unter Einbeziehung des Defaultwertes - automatisch erzeugt 
werden. 

Angebundene Prozeduren. In ObjTalk können Operationen auf Slots durch 
angebundene Prozeduren überwacht werden. Angebundene Prozeduren erlauben ein 
datenorientiertes Programmieren. Im Unterschied zur Aktivierung einer explizit defi- 
nierten Methode auf Grund von Nachrichten werden angebundene Prozeduren auf 
Grund von Slotzugriffen aktiviert. Angebundene Prozeduren sind mit Hilfe erweiter- 
ter Slotmethoden realisiert. Ein Zugriff auf einen Slot bedeutet in ObjTalk das Sen- 
den einer Nachricht. Für jeden Slot sind daher eigene Methoden definiert, die auf die- 
se Slotnachrichten reagieren. Diese Methoden werden vom System auf Grund ange- 
bundener Prozeduren erweitert . 9 



9 

In Framesprachen, in denen Slotzugriffe nicht mit Hilfe von Nachrichten realisiert sind, müssen die 
allgemeinen Slotzugriffsfunktionen die Existenz einer angebundenen Prozedur prüfen, bevor der tatsäch- 
liche Slotzugriff erfolgen kann. 




Koreferenzen. Frames eines Framesystems haben dieselben Terminale. Diese ent- 
sprechen in ObjTalk koreferenten Slots. Sie haben stets denselben Wert. Wird der 
Wert eines Slots gesetzt, modifiziert oder gelöscht, werden die Slotinhalte der zu die- 
sem Slot koreferenten Slots in der gleichen Weise verändert. 

In FINANZ sind Formulare oft nur Perspektiven auf dieselbe zugrundeliegende Daten- 
struktur. Unterschiedliche Formularfelder, die dieselbe Datenstruktur sichtbar ma- 
chen, sind mit Hilfe koreferenter Slots gleichgesetzt. 

Durch Gleichsetzen von Slots unterschiedlicher Klassen können Eigenschaften zwi- 
schen Klassen übertragen werden. Dadurch können Constraint-Net ze aufgebaut wer- 
den (Abschn. 3.7). 

3.5. Superklassen 

Frames sind dann für die Beschreibung einer Situation gut geeignet, wenn sie viele 
Einzelheiten eines Ereignisses oder Gegenstandes möglichst genau beschreiben. Am 
besten geeignet wäre also ein Frame, das nur auf genau eine Situation anwendbar ist. 
Dieser Extremfall tritt jedoch nicht auf, denn Frames haben den Zweck, von konkre- 
ten Einzelfällen zu abstrahieren. 

Frames beschreiben also Situationen nur angenähert. Sie können sehr genau sein oder 
von allgemeinerer Natur. Frames werden daher in einer Generalisations hi er archie 
angeordnet, an deren oberem Ende allgemeine und an deren unteren Enden spezielle 
Frames stehen. Spezialisierung kann dabei als Mengeninklusion, als logische Inferenz 
oder als Vererbung struktureller Eigenschaften interpretiert werden (5). 

In vielen Framesprachen wird das Prinzip der Spezialisierung entlang der Framehie- 
rarchie durchbrochen. Dort können Frameeigenschaften in Unterframes beliebig modi- 
fiziert werden. Dies hat zur Folge, daß keine sicheren Aussagen über Frames auf 
Grund ihres Platzes in der Vererbungshierarchie gemacht werden können (6). 

In ObjTalk werden entlang der Klassenhierarchie Eigenschaften vererbt. Eine 
Vererbungshierarchie kann nur als Generalisationshierarchie angesehen werden, wenn 
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in den Klassen Eigenschaften von Superklassen spezi fischer definiert werden. In ob- 
jektorientierten Programmiersprachen - also auch in ObjTalk - können Eigenschaften 
definiert werden, ohne daß damit notwendigerweise eine Spezialisierung einhergeht: 

• Methoden können vollständig ersetzt werden. 

• Neue Methoden, die das Verhalten erweitern, können hinzugefügt werden. 

• Zusätzliche Slots können definiert werden. 

Auch in den durch die Frametheorie motivierten Sprachan teilen von ObjTalk können 
Erweiterungen in Subklassen vorgenommen werden. 

Die Interpretation der Superklassenbeziehung in ObjTalk als Generalisationshierarchie 
ist also nur mittelbar möglich und hängt in starkem Maße von der Verwendung der 
Sprachmittel ab. 

Multiple Superklassen. Objekte eines Anwendungsbereichs gehören normalerweise 
mehreren Klassen an. Objekteigenschaften setzen sich daher aus den Eigenschaften 
mehrerer Klassen zusammen. Die Beschränkung auf eine strenge Hierarchie, in der 
Klassen höchstens eine Superklasse haben dürfen, führt daher zu Problemen. 

Klassen, die Fensterobjekte einer Bildschirmschnittstelle beschreiben, können in einem 
System mit strenger Hierarchie wie in Abbildung 3-4a angeordnet werden. 

Das Problem besteht darin, daß Form, Beschriftung und Rahmen orthogonale Merk- 
male sind. Sollen Fensterklassen mit allen Kombinationsmöglichkeiten zulässig sein, 
werden z.B. die Merkmale, die einen Rahmen beschreiben, an verschiedener Stelle der 
Hierarchie wiederholt. Dies kann dadurch vermieden werden, daß eine Klasse mehrere 
Superklassen haben kann, von denen sie Eigenschaften ererbt (Abb. 3-4b). 

Der Spezialisierungsbegriff für Klassenhierarchien behält auch bei der Verwendung 
multipler Superklassen seine Gültigkeit: Jede Klasse ist Spezialisierung jeder ihrer Su- 
perklassen. Das Verwenden mehrerer Superklassen erfolgt in Analogie zur Definition 
neuer Slots. Ererbte Eigenschaften werden nicht durch zusätzliche Restriktionen spe- 
zifischer definiert, sondern es kommen neue Beschreibungsmerkmale hinzu. 
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a) Strenge Hierarchie b) Hierarchie mit multiplen Superklassen 



Abbildung 3-4: Zwei Hierarchien von Klassen eines fensterbasierten Systems 



3.6. Regeln 

Auswahl und Angleichung von Frames an Situationen werden durch die Wertebele- 
gung der Terminale gesteuert. Dieser Prozeß ist von mehreren Terminalen abhängig. 
Er kann in ObjTalk mit Hilfe von Regeln realisiert werden. Regeln werden häufig 
durch die Veränderung des Objekt zustands aktiviert. 

Regelsysteme haben im Bereich von Expertensystemen eine große Bedeutung gewon- 
nen. In Produktionssystemen wird der Bedingungsteil der Regeln mit einem globalen 
Systemzustand verglichen. Die Ausführung der Regeln bewirkt eine Veränderung die- 
ses Systemzustands, so daß im nächsten Zyklus weitere Regeln ablaufen können (13, 
21 ). 

Die Definition einer Regel führt in ObjTalk zur Definition von Regelmethoden. Diese 
werden mittels Nachrichten aktiviert, die das Objekt auffordern, eine Angleichung an 
veränderte Gegebenheiten (z.B. eine veränderte Belegung der Slots) vorzunehmen. 

In ObjTalk ist der Systemzustand, mit dem die Bedingungsteile der Regeln verglichen 
werden, auf die Slots eines Objekts beschränkt. Es gibt keine globale Datenstruktur, 
auf die alle Regeln zugreifen. Die Vorteile dieser Regelorganisation liegen darin, daß 
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Teilprobleme lokal und relativ unabhängig von anderen Objekten gelöst werden kön- 
nen. Im Sinne der Aufgabendelegation repräsentieren Objekte Experten, denen das 
Expertenwissen in Form einer Regelmenge zugeordnet ist. Dadurch kann die Form 
der Regeln den Erfordernissen der Aufgabe angepaßt werden. Globale Zusammenhän- 
ge müssen durch expliziten Nachrichtenaustausch oder durch die Verwendung von Ko- 
nferenzen zwischen Slots unterschiedlicher Objekte gelöst werden. 

3.7. Constraints 

Zwischen den Terminalen von Frames sind Relationen definiert. In ÖbjTalk werden 
solche Relationen durch Constraints beschrieben. Constraints sind Bedingungen, die 
zwischen den Slotwerten eines Objekts eingehalten werden müssen. Während sich mit 
Hilfe von Slotbeschreibungen Restriktionen für jeweils einen Slot formulieren lassen, 
stellen Constraints Beziehungen zwischen verschiedenen Slots her. Zur Realisierung 
von Constraints werden Regeln verwendet, die die Abhängigkeiten zwischen den Slots 
prozedural beschreiben. 

Einfache arithmetische Constraints beschreiben den Zusammenhang zwischen Summe 
und Summanden oder zwischen Produkt und Faktoren. Die Constraints sind dabei als 
spezielle Obj Talk-Klassen (Abschn. 3.2) implementiert. Sie können wie andere 
Obj Talk-Klassen instantiiert werden. Durch Gleichsetzung von Slots solcher 
Constraint-Instanzen über die Koref-Beziehung (Abschn. 3.4) werden 
Constraint-Net ze auf gebaut. Die Abhängigkeit zwischen Wärmegraden in Celsius und 
Fahrenheit kann mit einem Constraint-Netz (Abb. 3-5) dargestellt werden (4, 22). Da- 
bei sind die Knoten Instanzen der jeweiligen Const rain t-Klasse. Wird einer der Slot- 
werte verändert, so pflanzt sich die Veränderung Uber die Verbindungskanten des 
Netzes fort, um die mit Hilfe der Constraints beschriebenen Konsistenzbedingungen 
aufrecht zu erhalten. 

Constraints leisten einen entscheidenen Beitrag, Obj Talk-Klassen als Frames zu ver- 
wenden. 

1. Mit Constraints können Eigenschaften von Objekten deklarativ beschrie- 
ben werden. Constraints charakterisieren Objekte, indem sie Bedingungen 
für die Wertebelegung der Slots festlegen. 
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Fahrenheit Celsius 




(Fahrenheit - 32) * 5 = Celsius * 9 
Abbildung 3-5: Die Beziehung zwischen Celsius und Fahrenheit als Constraintnetz 



2. Mit Constraints können Eigenschaften von Objekten prozedural beschrie- 
ben werden. Constraints repräsentieren nicht nur Bedingungen, die unter 
den Slots eines Objekte erfüllt sein müssen, sondern auch Regeln, wie die 
Konsistenz hergestellt werden kann. 

3. Constraints sind selbst Objekte. Bedingungen zwischen den Slots eines 
Objekts sind damit explizit repräsentiert. Dies hat zur Folge, daß Con- 
straints selbst Objekte der Betrachung sein können. Es können z.B. Bedin- 
gungen für Constraints oder Restriktionen für die Slots der Constraints 
formuliert werden. Dies trägt zum Metawissen des Systems bei. 

4. Schlußbemerkungen 

Wir haben gezeigt, wie Struktur und Prozesse von Frames mit Hilfe objektorientierter 
Programmierung beschrieben werden können. Objektorientierte Programmiersprachen 
sind generell gut geeignet, um Eigenschaften von Frames zu realisieren, denn eine Rei- 
he von Konzepten lassen sich leicht aufeinander abbilden: 

• Slots - Terminale 

Slots objektorientierter Sprachen entsprechen den Terminalen von Frames. 
Subframes, d.h. Frames, die Terminale von Frames Füllen, entsprechen Ob- 
jekten als Slotwerte von Objekten. 

• De faults - Erwartungen 

Voreinstellungen, Erwartungen und Annahmen in Frames entsprechen De- 
faultwerten in Slots von Objekten. 

• Spezialisierung - Vererbung 

Allgemeine Frames, die Situationen relativ ungenau beschreiben, können 
durch speziellere Frames konkretisiert werden. In objektorientieren Spra- 
chen wird spezialisiertes Verhalten durch Vererbung von Slots und Metho- 
den realisiert. 






- 84 - 



Einige Eigenschaften von Frames lassen sich dagegen nicht unmittelbar auf Objektei- 
genschaften übertragen: 

• Restriktionen 

In Frames bestimmen Restriktionen der Terminale, wie gut ein Frame ei- 
ner gegebenen Situation entspricht. Slotwerte in objektorientierten Spra- 
chen sind keinen Restriktionen unterworfen. 

• Abhängigkeiten zwischen Terminalen 

Die Eigenschaften von Frames sind auch durch Abhängigkeiten der Termi- 
nale untereinander beschrieben. Slotwerte in objektorientierten Sprachen 
unterliegen keinen besonderen Abhängigkeiten. 

• Framesysteme 

Framesysteme bestehen aus mehreren, gleichartigen Frames, deren Termi- 
nale mit denselben Werten gefüllt sind. In objektorientierten Sprachen 
existieren keine vordefinierten Mechanismen, mit deren Hilfe Slots von Ob- 
jekten desselben Systems anderen gleichgesetzt werden können und diese 
Abhängigkeit automatisch aufrecht erhalten werden kann. 

• Relationen zwischen Frames 

Wichtiges, beschreibendes Merkmal eines Frames sind Ähnlichkeiten und 
Unterschiede zu anderen Frames. Die einzige, vordefinierte Verbindung 
zwischen Klassen objektorientierter Sprachen wird durch die Superklassen- 
beziehung beschrieben. Es gibt keine weitere, vordefinierte Möglichkeit, 
Unterschiede und Ähnlichkeiten zwischen Klassen in objektorientiert Spra- 
chen zu beschreiben. 



Ais konkretes objektorientiertes Sprachsystem haben wir ObjTalk vorgestellt. In Obj- 
Talk sind framebasierte Erweiterungen mit Hilfe der objektorientierten Programmie- 
rung realisiert. Das Sprachdesign ist offen, so daß ObjTalk auch als eine Sprache ver- 
standen werden kann, die es erlaubt, Erweiterungen im Sinne der Frametheorie vor- 
nehmen zu können. 



ObjTalk wurde im Rahmen mehrerer Forschungsprojekte entwickelt. Es wird in vie- 
len Systemen aktiv eingesetzt (10). ObjTalk ist in FRANZLISP und ZETALISP imple- 
mentiert und steht auf VAX-, SUN- und Symboiics-Rechnern zur Verfügung. 
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Zusammenfassung 

Das zielgerichtete Lenken von Suchprozessen ist ein Schlüsselproblem in der Kl - 
Forschung. Der wissensbasierte Ansatz zur Lösung dieses Problems erfordert 
geeignete Konzepte zur Repräsentation von Problemlösungswissen und einen 
Interpreter ; der unter Verwendung des formal dargestellten Problemlösungswissen nach 

Lösungen sucht. In dieser Arbeit wird ein Wissensrepräsentationsformalismus zur 
Spezifikation benutzerdefinierter Kontrollstrategien in regelbasierten Systemen 

entwickelt. Der Ansatz basiert auf wenigen Grundkonzepten: Ausgangspunkt ist der 
Regelkomplex, mit dem Regelbasen strukturiert werden. Darauf aufbauend werden 
Kontrollstrategien als partielle bzw. vollständige Beschreibungen sinnvoller 

Interaktionsmöglichkeiten von Regelkomplexen eingefihrt. Eine Vielzahl von 
Kontrollstrategien kann durch Kombination der Konzepte Verkettung Metaregeln und 
Operatoren beschrieben werden. In dem hier dargestellten Formalismus werden 
Kontrollstrategien als Wissen und nicht als Programmkode dargestellt. Dies ermöglicht den 
Aufbau modularer, selbstdokumentierender und erklärungsfähiger Wissensbasen 

1. Motivation 

Für viele Aufgaben, die mit wissensbasierten Systemen gelöst werden sollen, sind besonders große 
Suchräume charakteristisch. Dies erfordert neuartige, an das zu lösende Problem angepaßte 
Kontrollstrategien, die selten zu Beginn des Systementwurfs bekannt sind und erst schrittweise 
entwickelt werden müssen. Man benötigt daher Formalismen, in denen Kontrollstrategien schnell und 
einfach spezifiziert und geändert werden können. 



Momentan verfügbare Expertensystem-Entwicklungsumgebungen stellen solche Formalismen nicht 
zur Verfügung. Sie sind entweder Shells, die nur eine fest vorgegebene Kontrollstrategie bereitstellen 
und deshalb sehr eingeschränkt sind (z.B. EMYCIN [1], MED1 [2]) oder aber hybride Systeme (KEE 
[3], BABYLON [4]). Hybride Systeme stellen zwar eine Vielzahl von 
Wissenrepräsentationsmechanismen zur Verfügung, die Kontrollstrategien müssen aber implizit als 
Programmkode dargestellt werden. Dieses Kodieren von Kontrollstrategien in Programmstücke führt zu 
schwer änderbaren, nicht modularen und nicht erklärungsfähigen Systemen. 
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In dieser Arbeit gehen wir von zwei grundlegenden Schwierigkeiten bei der Repräsentation von 
Kontrollwissen in zur Zeit verfügbaren Systemen aus: der impliziten Kodierung und der Vermischung 
von verschiedenen Arten von Kontrollwissen. Meta-Level Architekturen sind Programmarchitekturen, 
mit denen solche Schwierigkeiten beseitigt werden können. Wir stellen hier eine Sprache zur expliziten 
und deklarativen Repräsentation von Kontrollwissen vor, die es erlaubt, Meta-Level Architekturen zur 
Kontrolle von Suchprozessen zu spezifizieren. Die Sprache gestattet mit Hilfe von Regelkomplexen 
Regelbasen in Regelmengen zu partitionieren und die Voraussetzungen für die Anwendbarkeit und die 
Teilprobleme, die mit den Regelmengen gelöst werden sollen explizit anzugeben. Kontrollstrategien 
sind Beschreibungen für Reihenfolgen, in denen Regelkomplexe in einem Problemlösungsprozeß 
angewendet werden sollen und können durch verschiedene Konzepte beschrieben werden. Nachdem 
die wichtigsten Konzepte der Sprache vorgestellt sind, wird ein Beispiel für eine Regelbasis dargestellt 

2. Vermischung von verschiedenen Wissensarten in regelbasierten Systemen 

Eine weitere Möglichkeit für die Darstellung von Kontrollstrategien sind Produktionsregeln einer 
einfachen Regelsprache (wie OPS5 [5]). Um zu erklären, warum es schwierig ist, auf diese Art 
Kontrollstrategien zu repräsentieren, betrachten wir die folgende Produktionsregel einer komplexen 
Regelbasis. 



Wann ist 
die Regel« 
relevant? 



Schlußprinzip 



(rule UNDER1 

\ (phase INITIALIZE^ 

(not (under ?block2 ?block1 ?state)) - 
(on ?block1 ?block2 ?state) 

— ~> 

(add (under ?block2 ?block1 ?state))) 



Wann ist die 

Regelanwenung 

sinnvoll? 



Man kann die Bedeutung der Regel folgendermaßen beschreiben: Befindet sich der 
Problemlösungsprozeß in der Phase INITIALIZE, d.h. (phase INITIALIZE) ist ein Element der 
aktuellen Datenbasis, und gibt es in der Datenbasis eine Instanz des Musters (on ?blockl ?block2 ?state) 
und keine Instanz des Musters (under ?block2 ?blockl ?state), dann füge die instantiierte 
Symbolstruktur (under ?block2 ?blockl ?state) in die Datenbasis ein. 

Wieso ist diese Regel keine adäquate Darstellung des in ihr enthaltenen Wissens? 

Aus konzeptioneller Sicht beinhaltet diese Regel verschiedene Arten von Wissen, die in diesselbe 
Repräsentationsstruktur abgebildet werden: 

1. Wissen darüber, wann die Regel relevant ist. Im obigen Beispiel also nur während der Phase 
INITIALIZE. Regeln tragen i.a. etwas zur Lösung von Teilproblemen bei. Das impliziert, 
daß sie nur dann angewendet werden sollten, wenn der Problemloser das entsprechende 
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Teilproblem betrachtet. 

2. Wissen darüber, wann die Regel sinnvoll eingesetzt werden kann. Nämlich dann, wenn das 
Ergebnis ihrer Anwendung noch nicht explizit in der Datenbasis steht. 

3. Das Schlußprinzip. 

Die verschiedenen Arten von Wissen, die der Regel zugrunde liegen, können von Knowledge Engineers 
nur schwer unterschieden werden, was zu schlechter Wartbarkeit führt. Die syntaktische 
Ununterscheidbarkeit erschwert ausserdem die Generierung von Erklärungen. 

3. Ein Ansatz zur expliziten Repräsentation von Kontrollwissen 

In diesem Kapitel wird ein Wissensrepräsentationsformalismus für die Beschreibung von 
Problemlösungsverhalten entwickelt. Es wird versucht, eine möglichst kleine Menge kognitiv adäquater 
Konzepte bereitzustellen, durch deren Kombination Problemlösungsprozesse auf natürliche Art und 
Weise beschrieben werden können. 

Wir gehen dabei von einem mehrstufigen Problemlösungsmodell, einer Meta-Level Architektur zur 
Kontrolle, aus. Sie besteht aus einer Kontrollkomponente und einer Basisinferenzmaschine, wobei die 
Kontrollkomponente den Problemlösungszustand der Basisinferenzmaschine analysiert und ihre Suche 
steuert, indem sie ihr durch Aktivierung jeweils eine kleine Menge von Regeln zur Interpretation 
vorgibt. Als entscheidendes Kriterium einer Meta-Level Architektur wollen wir hier das Vorhandensein 
eines expliziten Modells der Basisinferenzmaschine ansehen, das heißt die Struktur und der Inhalt der 
Datenbasis, der Regeln (und Regelkomplexe) und der Kontrollstrategie sind explizit beschreibbar und 
sichtbar. 




Figur 1: Steuerung der Suche durch die Interpretation von Kontrollwissen 
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3.1. Strukturierung der Regelbasis - Regelkomplexe 

Oft bearbeiten Menschen Teilprobleme während eines Problemlösungsprozesses nacheinander und 
nicht gleichzeitig. Bildet man solche Vorgehensweisen in Kontrollstrategien von regelbasierten Systemen 
ab, werden Regeln immer nur dann angewendet, wenn sie zur Lösung des aktuellen Teilproblems 
beitragen. Es scheint deshalb sinnvoll zu sein Regeln nach inhaltlichen Kriterien den Teilproblemen 
zuzuordnen. Dies wird in der erweiterten Regelsprache CATWEAZLE durch das Konzept des 
Regelkomplexes ermöglicht. 

Um die Regelbasis effizient interpretieren zu können, muß die Kontrollinstanz des Regelinterpretierers 
Wissen über das in der Regelbasis befindliche Wissen besitzen (vgl. hierzu [6]). Besonders wichtig ist 
Wissen darüber, welche Voraussetzungen für die Anwendbarkeit eines Regelkomplexes gegeben sein 
müssen, bzw. welche Teillösungen herleitbar sind. Um dieses Wissen explizit darstellen zu können darf 
ein Regelkomplex nicht nur eine Menge von Regeln sein, sondern muss eine komplexere syntaktische 
Struktur besitzen. 

Ein Regelkomplex besteht aus einem Spezifikationsteil (der Namen des Regelkomplexes, seine Vor- 
und Nachbedingung) und dem Inhalt (einer Menge von Regeln). 

Die Vor- und Nachbedingung der Spezifikation sind Muster über Symbolausdrücken, aus denen die 
Datenbasis aufgebaut ist. Der Spezifikationsteil ist, im Gegensatz zum Inhalt, von aussen sichtbar und 
stellt eine Abstraktion des Regelkomplexes dar. Hier ist eine Abstraktion die Projektion einer 
komplexen Beschreibung auf wenige Merkmale, die bzgl. der betrachteten Klasse von Problemen wichtig 
sind. Für Regelkomplexe sind diese Merkmale die Anwendbarkeit, das Abbruchkriterium für ihre 
Interpretation und mögliche Ergebnisse. 

Die Struktur eines Regelkomplexes ist in Figur 2 veranschaulicht. 



Vorbedingung Name j?achbeclinguiu 



Regeln ueber Objektregeln 



Objekt reg ein 



Figur 2: Syntaktische Struktur eines Regelkomplexes 
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Die prozedurale Interpretation eines Regelkomplexes geschieht folgendermaßen: Regelkomplexe 
können von aussen aktiviert werden. Falls sie aktiviert und ihre Vorbedingung erfüllt sind, wird ihr 
Inhalt solange auf der Datenbasis interpretiert, bis entweder die Nachbedingung erfüllt ist, oder aber 
keine weitere Regel des Komplexes mehr anwendbar ist. 

Der Inhalt eines Regelkomplexes unterteilt sich in eine Objekt- und eine Meta-Regelbasis. Regeln der 
Objektebene geben an, in welchen Problemlösungszuständen welche Schlußfolgerungen gezogen 
werden können. Sie repräsentieren das Anwendungswissen des Experten. Regeln über Objektregeln 
(vgl. Metaregeln [7]) sind Produktionsregeln zur wissensbasierten Konfliktlösung. Sie geben an, welche 
von mehreren anwendbaren Regeln der Objektebene im Konfliktfall angewendet werden sollen. 



Die Gesamtwissensbasis besteht in diesem Ansatz aus einer Menge von Regelkomplexen und der 
Kontrollstrategie. 

3.2. Konzepte zum Beschreiben von Kontrollstrategien 

Eine Kontrollstrategie ist ein Modell, das der Knowledge Engineer erstellt, um die Verhaltensweisen 
und Vorgehensweisen eines Experten beim Problemlosen zu beschreiben, und von dem er annimmt, daß 
es die Vorgehensweise des Experten beim Problemlosen widerspiegelt. Kontrollstrategien bestimmen 
die Abfolge von Phasen in dem Problemlösungsprozeß. Phasen sind Abschnitte im 
Problemlösungsprozeß und bezeichnen den Regelkomplex, der während der Phase interpretiert werden 
soll. 

Kontrollstrategien spezifizieren, wie Regelkomplexe interagieren, um einen effizienten 
Problemlösungsprozeß zu bilden. 

Im folgenden werden drei Konzepte zur Formalisierung von Kontrollstrategien vorgestellt: 



1. Phasenfolgen, mit denen man die Reihenfolge der Ausführung der Regelkomplexe 
unabhängig vom aktuellen Problem festlegen kann. 

2. Operatoren, die es gestatten eine Reihenfolge, die dem aktuellen Problem angepaßt ist, mit 

einem Planungssystem zu bestimmen. 

3. Regeln über Regelkomplexen, die eingesetzt werden können, wenn zu viele 
unver hergesehene Variationen während des Inferenzprozesses auftreten und deshalb 
situationsabhängig entschieden werden muß, welcher Regelkomplex als nächster aktiviert 
werden soll. 
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3.2.1. Phasenfolgen 

Eine Phasenfolge ist eine Folge von Regelkomplexnamen. Die Aktivierung eines Regelkomplexes 
innerhalb einer Phasenfolge ist deterministisch. Die Phasenfolge wird schrittweise abgearbeitet. Durch 
die Phasenfolge, die aktuelle Phase und den Inhalt der Datenbasis ist die Folgephase eindeutig 
festgelegt. Im folgenden Beispiel wird die HYPOTHESIZE-AND-TEST Kontrollstrategie als 
Phasenfolge formuliert. 

phase-sequence HYPO THESIZE-AND- TES T 
ÜBERSICHTSFRAGEN 
(loop ERZEUGE-KRANKHEITSHYPOTHESE 
TES TE-KRANKHEITSHYPO THESE 
until { DIA GNOSE ( 7NAME-DER-DIA GN OSE, EVIDENT) } ) 

DIA GNOSE- UND- THERAPIEVORS CHLA G 
end-strateev 

Diese Phasenfolge beschreibt die folgende Problemlösungsmethode: Am Anfang stellt das System 
solange grundlegende Fragen, bis es alle notwendige Information erlangt hat, um eine Hypothese über 
die vorliegende Krankheit zu machen. Sobald das System eine Krankheitshypothese gefunden hat, die 
interessant genug erscheint, um weiter untersucht zu werden, wird diese Hypothese genauer getestet. 
Die letzten beiden Schritte werden solange wiederholt, bis eine Hypothese soviel Evidenz angesammelt 
hat, daß sie als gesichert gilt, oder aber keine Hypothese mehr interessant genug erscheint um weiter 
getestet zu werden. 

3.2.2. Regeln über Regelkomplexen 

Die Abstraktionen von Regelkomplexen, d.h. die Informationen darüber, wann Regelkomplexe 
einsetzbar sind und welche Teillösungen durch ihre Aktivierung erzielt werden können, erlauben einem 
Interpretierer der Repräsentationssprache, darüber zu reflektieren (vgl. [6]), welcher Regelkomplex im 
aktuellen Problemlösungszustand am effektivsten einsetzbar ist. 

Wenn Kontrollwissen als Regeln über Regelkomplexen formuliert wird, werden Regelkomplexe so 
interpretiert, daß sie immer dann anwendbar sind, wenn der momentane Problemlösungszustand die 
Vorbedingung des Regelkomplexes erfüllt. Dabei treten Konflikte auf, wenn mehr als ein 
Regelkomplex auf einen Problemlösungszustand anwendbar ist. Diese können durch zusätzliche 
Metaregeln, die situationsabhängige Bedingungen für die Aktivierung überprüfen, aufgelöst werden. 
Eine Metaregel, eine Regel in deren Bedingungsteil Muster von Objektregeln auftreten und deren 
Aktionsteil Objektregeln aktivieren oder suspendieren kann, wird im folgenden Beispiel gezeigt: 
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(metaregel mrl * 

(anwendbarer-Regelkomplex ?r 
(mit-Nachbedingung 

( Teilproblem ?namen-des-Teilproblems ist-gelöst))) 
(Teilproblem ?Namen-des-Teilproblems ist-gelöst) 

-> 

(verhindere-Anwendung ?r)) 



In der Metaregel "mrl*" wird folgende Konfliktlösungstaktik modelliert: Wenn ein Regelkomplex 
anwendbar ist, dessen Nachbedingung schon in der Datenbasis enthalten ist, ist eine Aktivierung des 
Regelkomplexes nicht sinnvoll. 

(metaregel mr2* 

(anwendbarer-Regelkomplex ?r 
(mit-Nachbedingung 
(Ziel ?X erfüllt))) 

(soll-gelöst-werden ?X) 

~> 

(aktiviere ?r)) 



Diese Metaregel drückt folgende Taktik bei der Konfliktlösung aus: Wenn in der aktuellen Datenbasis 
die Aussage enthalten ist, daß das Problem ?X gelöst werden soll und im aktuellen 
Problemlösungszustand ein Regelkomplex anwendbar ist, dessen Nachbedingung aussagt, daß das 
Teilproblem mit Namen ?X nach der Interpretation gelöst ist, dann ist es sinnvoll, diesen Regelkomplex 
zu aktivieren. 

3.2.3. Operatoren 

Abstraktionen von Regelkomplexen können auch als Operatoren in einem abstrakten Suchraum 
interpretiert werden, die einen Problemlösungszustand in einen anderen überführen. Solche 
Operatoren sind anwendbar, falls ihre Vorbedingungen erfüllt sind. Der Effekt ihrer Ausführung ist ein 
Problemlösungszustand, der die Nachbedingung des Regelkomplexes erfüllt. Das Kontrollwissen bei 
dieser Interpretationsform ist eine Wissensbasis für ein Planungssystem, das Wissen über den 
Anwendungsbereich besitzt und daraus für einen bestimmten Problemfall eine Reihenfolge für die 
Anwendung von Regelkomplexen konstruiert. 

Die Grundidee soll im nachfolgenden Beispiel kurz erläutert werden: Seien A, B, C und D 

Regelkomplexe mit den folgenden Abstraktionen: 

A: {Pi} A {P2,P4} 

B: {P3,P4)B {P5} 

C: {P2} C {P3} 

D: {PI} D {P6 } 
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So kann man die Abstraktionen als Operatoren in einem abstrakten Suchraum betrachten: 

A: Vorbedingung: {PI} 

Nachbedingung: {P2,P4 } 

B: Vorbedingung: {P3,P4} 

Nachbedingung: {P5} 

C: Vorbedingung: {P2} 

Nachbedingung: {PJ} 

D: Vorbedingung: {PI} 

Nachbedingung: {P6} 



Sei nun {P1,P8,P9} der initiale Problemlösungszustand und {P5} ein Muster für eine Problemlösung. So 
ist (A,C,B) eine Phasenfolge, die die Problemstellung in eine Problemlösung überführen könnte: 



{P1,P8,P9} 

-A-> {PJ f P2,P4 } P8,P9} 

-C-> {P1,P2,P3,P4,P8,P9} 
-B-> {P1,P2,P3,P4,P5,P8,P9} 



P5 ist in APPLY (B, (APPLY (C, APPLY (A, { P1,P8,P9 } ))) . Eine solche Phasenfolge kann von einem 
Planungssystem automatisch bestimmt werden. 

3.3. Beispiel zur Darstellung verschiedener Arten von Problemlösungswissen 

Die in Abschnitt 2 diskutierte Produktionsregel könnte in dem hier vorgestellten Ansatz wie in Figur 3 
dargestellt werden. 



Vorbedingung Name I Nachbedingung 






( metarule MR1* 

(objectrule ?orl 
(with-actions 

(add (under ?bl2 ?bll ? state)))) 
(under ?bl2 ?bll ?state) 

— > 

(suspend ?orl )) 



(rule UNDER1 
(on ?blockl ?block2 ? state) 

~ > 

(add (under ?block2 ?blockl ? state))) 










Figur 3: Repräsentation von verschiedenen Wissenstypen in Regelkomplexen 
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Wenn man die beiden Repräsentationen desselben Sachverhaltes vergleicht, so kann man feststellen, 
daß im vorgestellten Ansatz die in Abschnitt 2 isolierten Arten von Kontrollwissen aufgrund ihrer 
Repräsentationsstruktur unterschieden werden können. Wissen darüber, wann Regeln relevant sind, ist 
durch ihre Zuordnung zu Regelkomplexen, Wissen darüber, wann Regelanwendungen sinnvoll sind, sind 
durch die Regeln über Objektregeln dargestellt. Logische Schlußprinzipien werden durch Objektregeln 
formalisiert. 

Man kann ausserdem das Wissen auf verschiedenen Abstraktionsstufen darstellen und die Regelbasis 
bzgl. inhaltlicher Kriterien strukturieren. 

4. Ergebnisse der Arbeit 

1. Die Strukturierung des Problemlösungswissens in Regelkomplexe und die Beschreibung von 
Kontrollstrategien als Reihenfolge der Verwendung von Regelkomplexen beim Problemlosen sind in 
diesem Ansatz die entscheidenden Schritte zur Vereinheitlichung der Beschreibung von 
Problemlösungsmethoden. 

2. Die in Abschnitt 4 eingeführten Konzepte reichen aus, um die folgenden Klassen von 

Kontrollstrategien einfach und natürlich darzustellen: (1) Kontrollstrategien mit einer festen Folge 
abstrakter Schritte. Kontrollstrategien, die in diese Kategorie fallen sind u.a. Hypothesize- and-Test, 
Generate-and-Test, Establish-and- Refine oder auch die Kontrollstrategie von RI [8]. (2) 

Blackboard-basierte Kontrollstrategien. Dabei entsprechen die Regelkomplexe den "Knowledge 
Sources", der "Heuristic Scheduler" wird durch eine Menge von Regeln über Regelkomplexen 
realisiert [9]. (3) Kontrollstrategien, die durch ein Planungssystem an eine gegebene Problemstellung 
angepaßt werden können. 

3. Es ist möglich, die Struktur eines Problemlösungsprozesses so darzustellen, daß sie sich in der 
syntaktischen Struktur der Kontrollstrategie widerspiegelt. Das Behandeln von Kontrollstrategien als 
eine Art von Wissen ermöglicht es dem Knowledge Engineer modulare, selbstdokumentierende und 
erklärungsfähige Wissensbasen aufzubauen. 

4. Da die Interpretation von Kontrollwissen hochgradig mustergesteuert ist und Pattern-Matching die 
Teilaufgabe beim Inferenzprozeß ist, die den höchsten Zeitbedarf hat, werden bei der 
Implementierung dieses Ansatzes Kontrollstrategien in Bedingungsnetzwerke kompiliert. Die dabei 
verwendeten Bedingungsnetzwerke sind Erweiterungen der in [10] eingeführten und Bestandteil der 
meisten State-of-the-Art Systeme sind. Aus Effizienzgründen werden Objektregeln und 
Kontrollwissen in ein einziges globales Netzwerk übersetzt, wobei die externe Repräsentation des 
Wissens zu Erklärungs- und Tracezwecken jederzeit erzeugt werden kann. 
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5. Vom theoretischen Standpunkt aus betrachtet, definieren Kontrollstrategien reguläre Ausdrücke 
über Regelnamen [11]. Jede Inferenzkette (Folge von Regelnamen) ist in Bezug auf die 
Kontrollstrategie formal zulässig, falls sie ein Wort in der durch den regulären Ausdruck definierten 
Sprache ist. 

5. Beispiel: Planen in der "Blocksworld" 

In diesem Kapitel wird die erweiterte CATWEAZLE-Regelsprache anhand eines Beispiels vorgestellt 
und demonstriert, wie man damit eine adäquate Wissensbasis für das Blockumstapelproblem in der 
Blocksworld [12] aufbauen kann. 



Die Aufgabenstellung für das Blockumstapelproblem lautet kurz wie folgt: 



gegeben: Start- und Zielzustand, die jeweils eine Menge von Stapeln aus Blöcken beschreiben, in 
einer symbolischen Sprache 

gesucht: Aktionsfolge, die die Startsituation möglichst effizient in die Zielsituation überführt. 

Die externe Repräsentation von Situationen beim Blockumstapelproblem in der Blocksworld wird im 
folgenden Beispiel beschrieben: 



(fact (ontable a actual )) 
(fact (on b a actual )) 
(fact (on cb actual )) 
(fact (clear c actual)) 
(fact (ontable a goal)) 
(fact (on c a goal)) 

(fact (on b c goal)) 

(fact (block a actual)) 



Ausgangssituation : Zielsituation: 



C 



B 



A 



B 



C 



A 
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Die zu dem Problem gehörige Lösung ist: 



UNSTACK CB 
PUTDOWNC 
UNSTACKBA 
PUTDOWNB 
PICKUP C 
STACK CA 
PICKUP B 
STACK B C 



Die Arbeitsweise des Planungssystems für das Blockumstapelproblem läßt sich etwa wie folgt 
beschreiben: Das Planungssystem vergleicht ständig aktuelle Situation und Zielsituation und generiert 
aus der Differenz zwischen den Zuständen die möglichst beste Teilaufgabe. Durch schrittweise 
Generierung, Ausführung und erneuten Vergleich wird der Startzustand in den Zielzustand überführt. 



(production-rulebase planner-for-blocksworld 

(kind-of -strategy fixed) 

( phase-sequence (INITIALIZE 
(loop CHECK 

GENERATE-GOAL 
(until ((not (goal ***)))) 

SATISFY-GOAL))) 

(planning-system nil) 

(scheduler nil) 

(knowledge-source INITIALIZE 

...) 

(knowledge-source CHECK 

..,) 

(knowledge-source GENERATE-GOAL 
(precondition nil) 

( postcondition ( (goal ?x ?y ?z) ) ) 

( metarules 

(metarule CREATE-FIRST-STACK-GOALS 
(objectrule ?rl 
(with-actions 
(add (goal put-on **)))) 

-> 

(activate 1)) 

(metarule PREFER-PUTDOWN-GOALS-THAT-NEED-NOT-BE-RETRACTED 
(objectrule ?rl 
(with-actions 

(add (goal put-down ?block *))) 

(ontable ?blockgoal) 

— > 

(activate 1 )) 
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(object-rules 
(rule GENERATE 1 

(on ?blockl ?block2 goal) 

(clear Tblockl actual) 

(clear ?block2 actual) 

(status ?block2 satisfied) 

(status ?blockl unsatisfied) 

— > 

(add (goal put-on ?blockl ?block2))) 
(rule GENERATE2 
(ontable ?blockl goal) 

(clear ?blockl actual) 

(status ?blockl unsatisfied) 

— > 

(add (goal put-down ?blockl nil))) 
(rule GENERATE3 

(on ?blockl ?block3 goal) 

(ontable ?block2goal) 

(status ?block2 unsatisfied) 

(under ?block2 ?blockl actual) 

(clear ?blockl actual) 

(unless (status ?block3. satisfied)) 

~> 

(add (goal put-down ?blockl nil))) 

(knowledge-source SATISFY-GOAL 

...)) 



Hier werden kurz die, in der Beispielregelbasis enthaltenen Konzepte der erweiterten 
CATWEAZLE Regelsprache kurz erläutert. Das Kontrollwissen umfaßt die Angabe der Art der 
Kontrollstrategie und die Phasenfolge. Die Phasenfolge ist eine deklarative Beschreibung der 
Reihenfolge, in der die einzelnen Regelkomplexe beim Problemlösungsprozeß eingesetzt werden. Bei 
der Spezifikation von Phasenfolgen können Schleifen und Verzweigungen durch das LOOP- bzw. 
IF-Konstrukt beschrieben. Endbedingungen für Schleifen werden mit dem UNTIL-Konstrukt 
angezeigt. LOOP- und IF- Konstrukte können beliebig ineinander geschachtelt werden. 



Der Aufbau von Regelkomplexen wird anhand des Regelkomplexes GENERATE-GOAL dargestellt. 
Vor- und Nachbedingungen von Regelkomplexen sind Listen von Mustern für Datenbasiselemente. 
Der Inhalt von Regelkomplexen besteht aus einer Menge von Regeln über Objektregeln und 
Objektregeln. 



Die Vorbedingungen von Regeln über Objektregeln enthalten Beschreibungen von Objektregeln [7]. 
Die zweite Regel über Objektregeln im Beispiel bedeutet z.B.: Wenn es eine anwendbare Objektregel 
gibt, in deren Aktionsteil das Ziel etabliert wird einen Block auf den Tisch zu legen und dieser Block 
soll auch in der Zielsituation auf dem Tisch liegen, dann ist die Ausführung dieser Regel vorzuziehen. 
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Die Objektregeln in der CATWEAZLE-Regelsprache gleichen den Regeln anderer einfacher 
Produktionsregelsprachen, wie z.B. OPS5 [5]. 

6. Kurzer Oberblick über die Implementierung 

Der Interpretierer CATWEAZLE wurde auf einer Symbolics LISP-Maschine in ZETA-LISP 
implementiert. Die Kontrollkomponente wird bei der Compilierung von Regelbasen aufgebaut und 
dabei dem jeweiligen Typ der Kontrollstrategie angepaßt. Es sind zur Zeit zwei verschiedene Typen von 
Basisinferenzmaschinen implementiert: Ein einfacher OPS5- ähnlicher Interpretierer und ein nicht- 
monotoner Produktionsregelinterpretierer mit einer integrierten Reason-Maintenance-Komponente 

«13]). 

Basisinferenzmaschine und Kontrollkomponente sind als Objekte implementiert und kommunizieren 
über Message-Passing. Das Pattern-Matching erfolgt durch einen RETE- artigen Algorithmus, der um 
entsprechende Konzepte erweitert wurde, so daß auch Kontrollstrategien und die Struktur der 
Regelbasis in das Bedingungsnetz hineinkompiliert werden können. 

7. Ausblick 

Der Bericht beschreibt den momentanen Stand der Implementierung eines ersten Prototypen für ein 
kontrolliertes Produktionsregelsystem. Die wichtigsten Anforderungen für Erweiterungen, die sich im 
Laufe der Entwicklung als notwendig bzw. wünschenswert herausstellten, sind in der nachfolgenden 
Liste kurz beschrieben. 

1. Im Moment sind als symbolische Vor- und Nachbedingungen nur Konjunktionen von Mustern 
darstellbar. Ein weiteres Hilfskonstrukt ’all-rules-fired’ dient dazu in die nächste Phase umzuschalten, 
falls keine Regel des aktiven Regelkomplexes anwendbar ist. Dieses Hilfskonstrukt ist nicht 
erklärungsfähig. Eine Erweiterung der Bedingungssprache um weitere Operatoren, wie AND, 
IMPLIES und NOT, würde es ermöglichen das ’all-rules-fired’ symbolisch zu beschreiben. Eine 
Erweiterung der Bedingungssprache ist deshalb erforderlich. 

2. Eine weitere nützliche Erweiterung ist der Ausbau des Ansatzes zu einem ’open-ended system’ (vgl. 
[14]). Die Grundidee besteht dabei darin, daß ein vollständiges kontrolliertes regelbasiertes System ein 
Regelkomplex für eine übergeordnete Regelbasis ist. Diese Systemarchitektur ist vor allem für sehr 
komplexe integrierte Anwendungen nützlich. 

3. Die symbolische Beschreibung der Problemstellung 

4. Um sinnvoll mit CATWEAZLE arbeiten zu können, müssen in der Regelsprache Fragen an den 
Benutzer spezifizierbar sein und Antworten des Systems an den Benutzer gegeben werden können. 
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Zusammenfassung ( Abstract ) 

PARES ist ein Echtzeit-Expertensystem zum Einsatz in Leitwarten 
von Elektroenergie-Versorgungsunternehmen. 

Es besteht aus einem Interface zur direkten Ankopplung an den 
Prozeß, in dem Datenübernahme, numerische Vorverarbeitung und 
Synchronisation mit Prozeßereignissen ablaufen. Dieser Teil 
realisiert die prozedural gegebene oberste Ebene der Hand- 
lungsketten in der Prozeßbedienung. Die Beurteilung herauskri- 
stallisierter Einzelsituationen durch Heurismen erfolgt, indem 
diese Situationen in einem Expertensystem-Kern bearbeitet wer- 
den . 

Der Kern verarbeitet zeitabhängige Daten, ist aber von Pro- 
blemen der Echtzeitverarbeitung entkoppelt. Das Beurteilungser- 
gebnis fließt zurück in die obere Handlungsebene und wirkt dort 
auf den Fortgang des prozeduralen Anteils ein. 

Parallel ablaufende Ereignisse im Prozeß werden behandelt, 
indem mehrfache Instanzen der entsprechenden Expertensystem- 
Teile geschaffen werden, die parallel arbeiten. Interaktionen 
zwischen Einzelsituationen werden mit Hilfe der globalen Daten 
Uber den Prozeß erkannt und führen zum Aufbau entsprechender 
neuer Situationen. 



Schlüsselwörter: Ingenieurwesen, Kopplung mit konventionel- 
ler Datenverarbeitung (Echtzeitsysteme) 
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1 . Einleitung 



Unter Leittechnik verstehen wir das Gesamtgebiet der über- 
geordneten Überwachung, Steuerung und Regelung ganzer in- 
dustrieller Systeme bzw. Prozeßverläuf e. Ihre primäre Aufgabe 
ist die Koordinierung der Informationen über Zustandsänderun- 
gen, Meldungen und Meßwerte des Prozesses und deren Zusammen- 
hänge . 

Als gemeinsame Grundaufgaben aller Leitsysteme lassen sich 
hervorheben [33: 

Verbesserung der technischen Sicherheit und 

Erhöhung der Wirtschaftlichkeit. 

Der Einsatz von Expertensystemen (XPSen) soll die konventio- 
nelle Technik nicht ersetzen, sondern ergänzen (Bild 1), denn 
eine Reihe von Aufgaben und Problemen sind trotz des hohen 
Niveaus der derzeitigen Leitsysteme (Leitwarten) nur schwer 
oder gar nicht lösbar. Hierzu zählen u.a. die Optimierung von 
Netzauslastungen, die sich insbesondere unter der Berücksich- 
tigung der Kraftwerkseinsatzplanung bisher einer mathematischen 
Bearbeitung mit vernünftigem Aufwand entzogen hat, und die 
Behandlung von Notsituationen. Diese Aufgaben werden heutzutage 
einem erfahrenen Bediener überlassen, wobei die Ergebnisse sehr 
stark von dessen Kenntnissen abhängen [53. 




Bild 1 Leitwarte mit Expertensystem 
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In diesem Bericht wird der Einsatz von XPSen in Leit war ten von 
Energieversorgungsunternehmen (EVUs) näher betrachtet. Aus den 
vielfältigen Aufgaben, die bei der Netzführung anfallen, wurde 
für PARES der Problemkreis "Kurzschluß im Freileitungsnetz" 
herausgegriffen . 

Schwerpunkt der Untersuchungen an diesem Prototypen sind Pro- 
grammiertechniken und Methoden von Expertensystemen. Art, Aus- 
wahl und Detaillierungsgrad der Darstellung des Problems ordnen 
sich dieser Zielrichtung unter. Teile der angesprochenen 
Funktionen werden bereits von modernen, konventionell program- 
mierten Leit warten überdeckt. 



2. Allgemeine Anforderungen an ein XPS zur Prozeßkontrolle 
Zeitabhänqiqkeit 

Das XPS muß die zeitabhängigen Meldungen und Meßwerte des 
Prozesses sowie die zeitlichen Bezüge der Werte untereinander 
und zur Gesamtsituation verstehen ( Zeitabhängigkeit ) . Im Gegen- 
satz dazu arbeiten viele bekannte Diagnosesysteme (z.B. MYCIN, 
DIPMETER ADVISOR) mit einer statischen, zeitlich unveränder- 
lichen Situation. 

Echtzeitverarbeitung 

Neben der Zeitabhängigkeit ist die Echtzeitverarbeitung ( Real- 
Time ) eine weitere schärfere Anforderung an XPSe in der Leit- 
technik. Das XPS muß innerhalb kurzer, vom Prozeß verhalten 
vorgegebener Zeiten reagieren und Vorschläge unterbreiten, da 
später keine Einflußnahme auf das sich weiterentwickelnde 
Prozeßgeschehen mehr möglich ist. Diese Fähigkeit besitzen XPSe 
klassischer Prägung nicht. 

Direkte Datenübernahme aus dem Prozeß 



Ein echtzeit fähiges XPS kann die Verzögerung durch eine manuel- 
le Dateneingabe im Dialog mit dem Benutzer nicht hinnehmen. Die 
vom Prozeß gelieferten bzw. vom XPS angeforderten Daten müssen 
also mittels einer direkten Ankopplung an den Prozeß bzw. die 
konventionelle Warte übernommen werden. Benötigt das XPS für 
seine Arbeit Informationen, die nicht aus den Prozeßdaten ge- 
wonnen werden können (z.B. Wetterverhältnisse) so besteht na- 
türlich die Möglichkeit, den Anwender zu fragen. 
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Durchgängige Unterstützung des Benutzers 



Das XPS muß sich dem Benutzer durchgängig anbieten, das Ver- 
ständnis darf sich nicht nur auf Ei nze 1 s i t uat ionen des 
Prozeßgeschehens beschränken. Z.B. sollte ein Diagnosesystem, 
das den Anlagenbediener bei Fehlerlokalisierung und durch ein- 
leiten von Sof ortrnaßnahmen unterstützt hat, auch die Reparatur 
und nachfolgend die u.U. diffizile Phase, den Prozeß in den 
Normalbetrieb zurückzubringen, abdecken. 

Parallele Bearbeitung von Einzelsituationen 

Ein Diagnose - Sofortmaßnahmen - Reparatur - Zyklus kann 
durchaus einen oder mehrere Tage dauern. Soll das XPS in dieser 
Zeit nicht für weitere Aufgaben blockiert sein, muß es parallel 
alle vorliegenden Situationen bearbeiten und für den Benut- 
zerdialog die jeweils aktuelle auswählen. 

Erkennen von Zusammenhängen 

Einzelne Situationen können sich gegenseitig beeinflussen, 
etwa, weil sie denselben Anlagenteil betreffen oder weil eine 
Störung in einem Anlagenteil Auswirkungen in funktional davon 
abhängigen Anlagenteilen hat. Das XPS sollte solche Interaktio- 
nen erkennen und ggf. den Bediener auf die dadurch entstehende 
neue Situation aufmerksam machen. 



3. Lösung 

Als Grundlage für XPSe in der Leitwartentechnik dienen Systeme 
klassischer dialogor j entierter Ausprägung. Ein solches XPS ist 
somit ein Werkzeug zur Behandlung einer "eingefrorenen" Situa- 
tion (Snapshot). Diesen Teil nennen wir den XPS-Kern. 

Der Kern behandelt dabei durchaus zeitabhängige Probleme, da 
die Prozeßsignale Zeitfunktionen sind. Er ist aber nicht in der 
Lage, das Problem der Echtzeitverarbeitung zu lösen. Hierfür 
sind zwei Gegebenheiten verantwortlich: 

Die vom Prozeß eintreffenden Signale sind zunächst in dem Sinne 
unstrukturiert, daß weder der Zeitpunkt, zu dem ein vom Kern zu 
bearbeitender Snapshot (Situation, Aktion) zu bilden ist; noch 
die Art der dazu notwendigen Signalzusammenfassung und Vorver- 
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arbeitung gegeben 1st. 

Es erscheint nicht zweckmäßig, den Kern um diese Aufgaben 
erweitern zu wollen, da dann notwendige elementare Eigenschaf- 
ten des Kerns verlorengehen. 

Die Verbindung der Prozeßwelt mit der Welt des XPS-Kerns stellt 
ein Interface her (Bild 2). Dieser Baustein unseres Expertensy- 
stems ist dafür verantwortlich, daß ein echtzeitfähiges XPS mit 
Leistungsmerkmalen, die über die eines klassischen dialog- 
orientierten Systems hinausgehen, entsteht (vgl. auch 121 und 
C4] ) . 

Der Schwerpunkt der nachfolgenden Betrachtungen liegt deshalb 
auf diesem Teil des XPS. 




Bild 2 Interface zwischen Prozeß und XPS-Kern 
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3 . 1 Interface 

Das Interface muß den in Echtzeit ablaufenden und sich ständig 
weiterentwickelnden Prozeß beobachten und solche Situationen 
erkennen, die der weiteren Beurteilung durch den nicht echt- 
zeitfähigen Kern bedürfen. 



3.1.1 Parallel Struktur 

Nach einer Kernbeauftragung läuft das Interface parallel zum 
Kern weiter, denn während der Bearbeitung eines Ereignisses 
durch den Kern muß überprüft werden, ob die Voraussetzungen für 
die Kernbeauftragung noch gelten oder ob eventuell wichtige 
Veränderungen im Prozeßablauf eingetreten sind, die dazu ge- 
führt haben, daß die dem Kern übergebene Situation das tatsäch- 
liche Prozeßgeschehen nicht mehr beschreibt. 

Diese Konzeption findet Anwendung auf sämtliche Ereignisse in 
der Prozeßführung. Da aber in der Regel mehrere Ereignisse 
gleichzeitig vorliegen, müssen diese auch wieder parallel bear- 
beitet werden. So entsteht eine Multitasking-Struktur des ge- 
samten Systems, in dem sich einzelne parallel laufende Rechen- 
prozesse um einzelne Aspekte des Prozeßgeschehens kümmern (Bild 
3) . 




Bild 3 Parallele Aktionen im Expertensystem 
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Da die Leistungsfähigkeit der Hardware - insbesondere im Hin- 
blick auf die Verarbeitungsgeschwindigkeit - beschränkt ist, 
ist es notwendig, die Prozesse als konkurrierend zu betrachten. 
Gelöst wird das Konkurrenzproblem dadurch, daß den einzelnen 
Ereignissen (Prozessen) Prioritäten zugeteilt werden. 



3.1.2 Innere Struktur des Interfaces und des Kerns 

Das Gesamtsystem besteht aus Datenbeständen und Methoden, die 
global für sämtliche parallelen Rechenprozesse verfügbar sind 
und aus den lokalen Methoden und Daten der jeweiligen Prozesse. 

Die globale Information beinhaltet eine Anlagenbeschreibung. In 
dieser Beschreibung sind sämtliche Komponenten, aus denen sich 
der zu steuernde Prozeß zusammensetzt (Leitungen, Transformato- 
ren usw.) und Beziehungen (wer ist mit wem wie verbunden) 
aufgeführt. Dieses Wissen Uber den Prozeß heißt Anlagenwissen. 

In der Signalwelt werden die zeitlich veränderlichen Signale 
aus dem Prozeß (Spannungen, Ströme an Meßpunkten usw.) erfaßt. 



3 . 2 Von den Signalen zur Kernbeauftragung 

Die Übersetzung der Information aus der Signalwelt, in der das 
Wissen Uber den Prozeß zustand in Form numerischer Werte der 
einzelnen Signale vorliegt, in die symbolische Form einer Ak- 
tion, die dann ihre endgültige Beurteilung im Zusammenwirken 
mit dem Kern erfährt, erfolgt in drei Stufen. 

Der erste Schritt erfolgt noch in der Signalwelt. Numerische 
Verknüpfungen von Signalen (z.B. Trendberechnungen oder Filte- 
rungen), die speziell für das Expertensystem benötigt werden, 
und die in der konventionellen Warte in dieser Form nicht 
vorliegen, werden hier erledigt. 

Überschreitungen von Schwellen oder sonstige erkennbare Trends 
dieser Signale bzw. ihrer bewertenden Kombination liefern die 
ersten Situationen, aus denen die Kandidaten für die Kernbeauf- 
tragung resultieren sollen. Diese Ebene der Informationsdar- 
stellung heißt Situationswelt. 

Weitere Beurteilung der Situationen führt zu den Aktionen. Die 
Aktion bearbeitet Teilprobleme dadurch, daß sie bestimmte fest- 
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umrissene Gegebenheiten dem Kern (genauer einem Rechenprozeß 
mit Kerneigenschaft, es sind u.U. mehrere parallel tätig) zur 
Bearbeitung übergibt. Von dort kehrt die Kontrolle im Verlaufe 
der Bearbeitung eines Problems immer wieder in die Aktionswelt 
zurück. Dies geschieht, wenn Verarbeitungsschritte wie Synchro- 
nisation mit externen Ereignissen, Ablauf von Zeitintervallen 
usw. anstehen, die der Kern mit seinen Mitteln nicht realisie- 
ren kann. Die Bearbeitung durch das Interface ist also nicht 
nur einmalige Vorverarbeitung (vgl. Bild 4)! 



3 . 3 Zusam m enwirken von Einzel Situationen 

Das Konzept der parallelen Bearbeitung kennt keine überge- 
ordnete Stelle mit Gesamtüberblick. Durch den Prozeß vorhandene 
Interaktionen der Einzelsituationen erkennen diese selbst 
dadurch, daß sie auf gleiche Anlagenteile oder auch funktional 
zusammenhängende Anlagenteile der globalen Datenbasis zugrei- 
fen. Eine erkannte Interaktion ist dann in der Gesamtheit eine 
neue Situation, die entsprechend bearbeitet werden muß und ggf. 
zum Abbruch der Bearbeitung der Einzelaspekte führt. 



Prozeßdaten 




Ergebnisse 



Bild 4 Grundsätzliche Struktur des Expertensystems 
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4. PARES 



PARES ist zum Teil bereits auf einer Symbolics realisiert. 
Grundsätzlich erfolgt die Programmierung objektorientiert. 
Nicht nur Daten, sondern auch die einzelnen Rechenprozesse sind 
Objekte (Frames) mit entsprechenden Eigenschaften, eben 
Prozeßeigenschaften. Der XPS-Kern ist ebenfalls ein Frame, der 
Prozeßeigenschaften besitzt. Bei jeder Beauftragung wird eine 
neue Instanz des Kerns geschaffen. Durch Parametrisierung wird 
di^se nur mit dem für die jeweilige Aufgabe bestimmten und 
ausgewählten Regelpaket (en) gestartet. Die Abarbeitung der 
Regeln erfolgt, wenn nicht anders erwähnt, durch Vorwärtsaus- 
führung. Der XPS-Kern in PARES sowie einige Strukturen des 
Interfaces machen von dem XPS-Tool Babylon CI] Gebrauch. Zum 
prinzipiellen Aufbau und Ablauf einer Wissensbasis in Babylon 
vgl. CI 3. 

Die nachfolgende Schilderung gibt die wesentlichen Handlungsab- 
läufe in PARES an. 



4 . 1 Wissen 

4.1.1 Anlagenwissen und Signalwelt 

Die Anlagen-Wissensbasis von PARES umfaßt ca. 8000 Instanzen 
der Frames: Umspannwerk, Schal t station , Einfacher- (Lei- 
tungs ) knoten, Leitung(sabschnitt) und Schalter. 

Die Signalwelt besteht aus analogen Meßwerten, den Strömen und 
Spannungen an bestimmten Stellen des Netzes, die sich in Abhän- 
gigkeit von dem Verhalten der Verbraucher ständig neu einstel- 
len und den diskreten Werten der aktuellen Stellungen der 
Schalter im Netz. 



4.1.2 Betriebs wissen - Erkennen des Kurzschlusses 

Jede Änderung einer Schalterstellung wird von der konventio- 
nellen Warte an PARES gemeldet und in der Signalwelt im Slot 
"Iststellung" der zugehörigen Instanz von "Schalter" abgelegt. 

Im Ausgangszustand ist an die Werteslots aller Leistungsschal- 
ter eine Instanz eines Frames "Kurzschluß-erwartet" als Element 
einer sogenannten Exportliste angehängt, die bei sämtlichen 
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Schalthandlungen angestoßen wird und Überprüft, ob es sich um 
eine Schalterauslösung durch Kurzschluß handelt. Die bekannte 
Vorgehensweise, Methoden so an Slots von Instanzen anzubinden, 
daß sie beispielsweise bei Setzen des Slotwertes ablaufen ist 
hier dahingehend modifiziert, daß die Abarbeitung der Methode 
in einem anderen Prozeß (im Sinne des Betriebssystems des Rech- 
ners) erfolgt. Dadurch wird die Parallelität der Bearbeitung 
erreicht . 

Durch Zugriff auf den entsprechenden Slot des Schalterobjektes 
kann festgestellt werden, ob es sich um eine Überstromauslösung 
(Kurzschluß) gehandelt hat. Für jede über stromaus lösung wird 
eine Instanz des Frames "Kurzschluß-bearbeitet" geschaffen und 
mit dem Schalterobjekt und einem Verweis auf die schaffende 
Instanz initialisiert. Damit ist ein eigenständiger Prozeß 
parallel zu den übrigen Abläufen geschaffen. 



4 . 2 Bearbeitung des Kurzschlusses 

Die startende Instanz des Frames “Kurzschluß-bearbeitet" ver- 
wendet das Anlagenwissen einschließlich der dort stehenden 
aktuellen Schalterstellungen, um diejenigen Schalter zu ermit- 
teln, die an vom Kurzschluß betroffenen Netzteilen hängen 
(Pfadverfolgung im Netz). Es wird eine Instanz des XPS-Kerns 
kreiert und gestartet. Ausgehend von einer Stelle, an der eine 
Schalterauslösung stattgefunden hat, werden rekursiv über die 
Leitungen die betroffenen Schalter ermittelt. Abbruchkriterien 
sind dabei gegeben durch das Erreichen einer Schaltstation, 
eines Umspannwerkes oder eines offenen Schalters, wobei es 
zunächst uninteressant ist, ob der Schalter sich betriebsmäßig 
oder aufgrund eines Kurzschlusses in geöffnetem Zustand befin- 
det. Ergebnis ist eine Liste mit den betroffenen Schaltern, die 
an die Instanz des Frames "Kurzschluß-bearbeitet" gegeben wird 
(Bild 5). 

Aus den Exportlisten sämtlicher Schalter von dieser Liste (ein- 
schließlich der Handschalter) werden zunächst die Verweise auf 
ihren Kreator entfernt, denn der soll sich mit den weiteren 
Dingen, die in diesem Anlagenteil geschehen, nicht mehr be- 
schäftigen. Die aus den Exportlisten entfernte Information wird 
innerhalb der eigenen Instanz aufgehoben, um bei Abbau der 
Instanz (nach getaner Arbeit) den ursprünglichen Zustand ermit- 
teln zu können. 
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Bild 5 Handlungsablauf bei Leitungskurzschluß 



4.2.1 Gewinnung von Gesamt Zusammenhängen 

Weiterhin demonstrieren diese Einträge, wie aus lokaler Kennt- 
nis heraus durch Verknüpfung über das Anlagenwissen Gesamtzu- 
sairanenhänge ermittelt werden, die dem System zunächst nicht 
bekannt sind. 

Ermittelt die Instanz in einer Exportliste eines Schalters 
bereits einen Zeiger auf eine andere Instanz ihres eigenen 
Types, so hat es offenbar zwei Schalterfälle mit kausalem 
Zusammenhang gegeben. In diesem Fall löscht sich die Instanz. 

Der Wiedereintrag der Information in die Exportlisten erfolgt 
durch Starten einer Kerninstanz mit entsprechendem Regelpaket. 
Der einfache Wiedereintrag der Information, die beim Start der 
Instanz entfernt wurde, ist nicht immer sinnvoll, z.T. sogar 
falsch, da andere Funktionen (außerhalb des Problemkreises 
"Kurzschlußbehandlung") ebenfalls Exportlisten von Signalen 
verändert haben können. Was wieder in die Exportlisten einge- 
tragen werden soll, entscheidet dieses Regelpaket unter Berück- 
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sichtigung des gesamten Prozeß zustandes. 

Um zu vermeiden, daß sich sämtliche Instanzen in dem Glauben, 
die andere wird es schon richten, abbauen, sorgen Verriege- 
lungsmechanismen zwischen den Prozessen dafür, daß eine Instanz 
erhalten bleibt. 



4.2.2 Erster Wiedereinschaltversuch 

Dies geschieht, indem die Instanz von "Kurzschluß-bearbeitet" 
für jeden ausgelösten Leistungsschalter eine Instanz von "2- 
min-Aktion" schafft, die die Probeschaltung nach Ablauf von 2 
Minuten durchführt. 

Ihre erste Aufgabe ist es, die Exportliste des Leistungs- 
schalters auf sich selbst zeigen zu lassen, die Details laufen 
ab wie schon geschildert. Dann schafft die Instanz eine Instanz 
eines Frames "Timer". Dem Timer wird die Wartezeit übergeben 
und der Name einer Methode der schaffenden Instanz, die nach 
Ablauf der Zeit angestoßen werden soll. 

Der Timer läuft ab und startet die ihm als Parameter übergebene 
Methode. Der Operator erhält die Meldung, den Leistungsschalter 
zu schließen. An Hand der Meldung des Schalterobjektes erfährt 
die Instanz von " 2 -min-Aktion" das Ergebnis und meldet es an 
ihren Schöpfer zurück, der für die weitere Beurteilung zustän- 
dig ist. Dies deshalb, weil die weitere Entscheidung davon 
abhängt, ob sämtliche betroffenen Leistungsschalter wieder 
halten oder ob mindestens einer wieder öffnet. Kenntnis aller 
Leistungsschalter ist aber nur in der höheren Hierarchiestufe 
der Instanzen vorhanden, die untere Instanz hat nur das Teil- 
problem "Probeschaltung an einem Leistungsschalter" zu bearbei- 
ten . 



4.2.3 Ergebnisbeurteilung Probeschaltung 

Sind sämtliche Ergebnisse eingetroffen, verwendet die Instanz 
"Kurzschluß-bearbeitet" für weitere Entscheidungen ein Regelpa- 
ket, das im Kern bearbeitet wird. War der Kurzschluß nur vor- 
übergehend, baut sich die Instanz ab. Anderenfalls geht es in 
die weitere Fehlerbehebung, bei der zunächst auf das Auftrennen 
des betroffenen Netzes gewartet werden muß. Das System macht 
einen Vorschlag, welcher Handschalter geöffnet werden sollte. 
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Aus dem Anlagenwissen, das auch Informationen Uber den geo- 
graphischen Netzaufbau enthält (z.B. "Schalter ist leicht er- 
reichbar" oder "Schalter liegt in einem Verzweigungsknoten"), 
ermittelt die Kerninstanz, unter Berücksichtigung weiterer 
Bedingungen wie z.B. der, daß der Schalter möglichst in der 
Mitte des betroffenen Leitungsnetzes liegen sollte (Minimierung 
des Suchaufwands), den am schnellsten und sinnvollsten zu betä- 
tigenden Handschalter. 

Parallel hierzu wird ermittelt, ob Schaltstationen spannungslos 
sind. Gibt es solche, wird für jede Station eine Instanz des 
Frames "Alternative-Versorgung" geschaffen. Diese Instanz 
versucht, durch Anwendung entsprechender Regelpakete für den 
Zeitraum der Störung nicht versorgte Stationen von anderen 
Speisepunkten aus zu versorgen. 



4.2.4 Weitere Fehlerbehebung 

Wird ein Handschalter im betroffenen Gebiet geöffnet, werden 
die beiden dadurch gebildeten Teilgebiete des Netzes ermittelt. 
Zwei Instanzen von "Probeschaltung" übernehmen die Durchführung 
einer solchen für je ein Gebiet. 

Erfolgreiche Probeschaltungen führen dazu, daß Netzteile wieder 
versorgt sind, sie bleiben bestehen. Nicht erfolgreiche Probe- 
schaltungen bedeuten unerwünschte Separation von Netzteilen und 
werden wieder rückgängig gemacht. 

Dieser Handlungsablauf wird wiederholt, bis der Fehler loka- 
lisiert worden ist. 



4.2.5 Rückkehr in den Normalzustand 

Die erfolgreiche Reparatur der Schadensstelle wird der Schnitt- 
stelle mitgeteilt und veranlaßt den Ablauf einer Methode in der 
Instanz von "Kurzschluß -bearbeitet", entsprechend der notwendi- 
gen Übersicht über das Gesamtproblem. 

Rückkehr des Netzes in den ursprünglichen Zustand erfolgt 
dadurch, daß eine Liste von Schaltbefehlen ausgegeben wird, die 
sämtliche Schalter wieder in den Ausgangszustand versetzen. 
Zwei Regelpakete des Kerns sorgen dafür, daß die Schalthand- 
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lungen zweckmäßig gewählt wird. Das eine Regelpaket überprüft, 
ob die Voraussetzungen zur Betätigung eines Schalters erfüllt 
sind, veranlaßt ggf. Handlungen zum Erreichen dieser und teilt 
dem Benutzer schließlich mit, Schalthandlung (öffnen oder 
Schließen) vorzunehmen ist. Dieses Regelpaket wird rückwärts 
ausgeführt. Das andere Regelpaket ermittelt aus den durchzufüh- 
renden Schaltungen die optimale Reihenfolge. Hierbei ist zu 
berücksichtigen, daß in möglichst wenigen Gebieten für einen 
möglichst kurzen Zeitraum der Strom abgeschaltet wird. 



5. Ausblick 

Wir können hier nur in die nähere Zukunft blicken. PARES, das 
wir als prototypisch für XPSe in Leitwarten ansehen, wird 
weitergeführt. Dazu gehören Akzeptanztests, in denen wir die 
erreichte Funktionalität mit Wartenpersonal diskutieren und 
versuchen, Vorschläge aufzunehmen. 

Die Entwicklung einer geeigneten Erklärungskomponente ist eine 
weitere Aufgabe. Sie muß in erster Linie dem Bediener Vorschlä- 
ge, die das XPS macht, in seiner Fachsprache erläutern. 

Außerdem gehört dazu die Erweiterung der Wissensbasis - über 
den bisherigen Rahmen hinaus - zu einem System, das sämtliche 
Aspekte des Wartenbetriebs erfaßt. So entsteht der Grundstein 
für einen breiten industriellen Einsatz der Expertensystemtech- 
nologie in der maschinellen Führung und Überwachung technischer 
Prozesse . 
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EXPERTENSYSTEME ZUR FEHLERDIAGNOSE 
AN CNC-MASCHINEN 



Dipl. Inform. Ralf Eichhorn 
Dipl. Inform. Ralf D. Pütz 
Dipl. Ing. Jürgen Ziegler 
Fraunhofer Institut (IAO), Stuttgart 



Zusammenfassung: Die Technologie von CNC-Maschinen hat in den 
letzten Jahren große Fortschritte gemacht. Die Mikroelektronik ermöglicht die 
Lösung immer umfangreicherer Automatisierungsaufgaben. Die Wirtschaftlichkeit 
eines derart komplexen Fertigungssystems hängt aber nicht allein von seinem 
Automatisierungsgrad ab, sondern die Zuverlässigkeit und Verfügbarkeit sind von 
entscheidender Bedeutung. 

Hier bieten KI-Techniken neue Unterstützung an. Mit Hilfe eines in die 
CNC-Maschine integrierten . Expertensystems kann der Bediener vor Ort eine 
Fehlerdiagnose durchführen. Durch dieses System wird er im Dialog angeleitet, 
gezielt nach Fehlern zu suchen und sie nach Möglichkeit selbst zu beheben. Als 
besonders problematisch bei der Entwicklung eines solchen Systems haben sich die 
Wissensakquisition, die Behandlung von Montagearbeiten während der Diagnose 
und Integration in die Zielmaschine erwiesen. Dieses Papier stellt unsere Arbeiten 
auf diesem Gebiet vor. 
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1. Problem Stellung 



Der Markt im Bereich von CNC-Maschinen hat in den vergangenen 
Jahren immer höhere Anforderungen an diese gestellt. So geht der Trend hin zu 
kleineren Losgrößen und zur Herstellung schwierigerer, sehr komplexer Teile. 
Trotz dieser Anforderungen werden kürzere Durchlaufzeiten und eine optimale 
Ausnutzung von Werk- und Schneidstoffen gefordert. 



Steuerung 




Antriebe 


• B*ut*ii«uiraii 




• EleMr. Fehler 

• Oberleitung 

• Paramel er Ander ong 


■ Lesefehler 
• halte Lötstelle 


• Speicher fehler 



interne 






■ Fehl just le rung 




^SSS 


* Verictmu tiling 






• Temperatur 







ÜMPClf 



• Temperatur 

• Feuchtigkeit 

• Boden sch vnngungen 



Ehnfluftgrcften auf 
7 uver Engigkeit 
und Verfügbar keil 



Maschinen . 
konittHdini 

* Vvr K hl«i(l 

* Temperatureinfluft 

* U^IUrcichRtdc 
Festigkeit 



Wen ith 




Werks tucta 


■ Bedient ehlrr 

* Falsche Vorgaben 

• Wen fehler 




* Werk Stoff 
e Abtrag 

• Gefügt 



•us: Industrie Anieiger 81 , Nr. 62 . W. Eversheim et «I. 
Maschinendiagnose in der automatisierten Fertigung 



Wer Li eng 




! * ! i 


* Werkteugrihl 
a Verse hleill 

* Bruch 

* Einspannung 




m 



Bild 1: Einflußgrößen auf CNC-Maschinen 



Diese hohen Marktanforderungen haben zu ebenso hochentwickelten 
CNC-Maschinen bis hin zu flexiblen Fertigungssystemen geführt. Derart kom- 
plexe Maschinen garantieren weitgehende Automatisierung, Flexibilität und einen 
hohen Funktionsumfang. Dies allein bestimmt aber noch nicht die Wirtschaft- 
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lichkeit. Eine hohe Zuverlässigkeit und Verfügbarkeit müssen auch wegen der 
hohen Kapitalbindung einer Maschine gegeben sein. Zu deren Erhöhung gibt es 
prinzipiell zwei verschiedene Verfahren: 

- Vorbeugung 

- Fehlerbehebung 

Die Vorbeugung geschieht größtenteils bei der Konstruktion einer Maschine, also 
beim Hersteller. Vorbeugende Maßnahmen sind besonders dann wichtig, wenn 
man bedenkt, daß der Produktlebenszyklus neuer Maschinengenartionen immer 
kleiner wird und somit das Ausreifen eines Maschinentyps in immer kürzeren 
Zeiten geschehen muß. 




Bild 2: Erhöhung der Verfügbarkeit und Zuverlässigkeit von CNC-Maschinen 

In Störfällen bzw. bei Stillstand der Maschine muß der Fehler möglichst 
schnell vor Ort behoben werden können. Anzustreben ist, daß der Maschinen- 
bediener den Fehler in vielen Fällen selbst beheben kann. Ist dies nicht möglich, 
sollte er oder ein Kommunikationssystem zumindest eine qualifizierte Diagnose 
übermitteln. Hierzu fehlt dem Bediener im allgemeinen aber das Know-how. 
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Erschwerend kommt hinzu, da/? sich die Art der auftretenden Fehler bei 
hochentwickelten CNC-Maschinen verändert hat: 

Fehler sind trotz erhöhter Komplexität seltener. Wenn sie auftreten, sind 
sie aber schwieriger und stellen selbst an einen Servicetechniker hohe 
Anforderungen. 

Fehler treten häufiger in der Anlagenperipherie auf, bedingt durch die 
immer größere Eigenkomplexität dieser Anlagen. 

Schnelle Änderungen der Maschinentypen bzw. deren Konfigurierungen 
z.B. mit Peripheriegeräten verknappen das gesamte Know-how im Ser- 
vicebereich. 

Durch die weite Verbreitung der Maschinen wird die schnelle 
Verfügbarkeit der Servicetechniker sehr aufwendig. 

Aufgrund der Anteile verschiedener Technologien aus den verschieden- 
sten Bereichen (z.B. Hydraulik, Mechanik, Elektrik) ist das Wissen nicht 
mehr bei einem einzigen Experten zusammengefaßt. 

Durch die Entwicklung modularer Maschinen wird die Behebung eines Fehlers in 
den meisten Fällen selbst von Laien durchführbar. Allerdings ist das Problem des 
Fehlerfindens, d.h. der Maschinen diagnose, nicht überschaubar, obwohl Schalt- 
und Konstruktionspläne oder Handbücher und Dokumentationen vorhanden sind. 
Hier stößt auch die konventionelle Datenverarbeitung an ihre Grenzen, denn eine 
noch so ausgefeilte Sensortechnik kann das Wissen eines Servicetechnikers nicht 
erfassen. Hier spielen Erfahrungswerte und allgemeine Kenntnisse eine tragende 
Rolle. 
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2. Architektur eines Ex per ten systems 



Bild 3 zeigt eine schematische Darstellung der Hauptkomponenten von 
Expertensystemen. 




Experte / Wissensingenieur Benutzer 



Bild 3: Architektur von Expertensystemen 

Die Wissensbasis bestimmt einen Unterschied zur herkömmlichen Pro- 
grammierung. Das Schlagwort "wissensbasierte Systeme" erhält seinen Charakter 
nicht dadurch, da/? in solchen Systemen erstmalig Wissen verarbeitet worden 
wäre, sondern dadurch, da/? hier im Gegensatz zur impliziten Wissensdarstellung 
in üblichen Programmen erstmals explizite Wissensstrukturen angelegt werden. 

Die Wissensbasis ist über eine Schnittstelle, den Wissenseditor, 
veränderbar und erweiterbar. Ein komfortabler Wissenseditor, der es erlaubt, eine 
leere Wissensbasis aufzufüllen, ist Kennzeichen eines Expertensystemstools bzw. 
einer Expertensystemshell. Fakten und Regeln können unabhängig von der 
Reihenfolge und relativ frei von einengenden Formalismen eingegeben werden, 
ohne da/? die Programmstruktur verändert werden mü/?te. 
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Der Inferenzmechanismus hat die Aufgabe, aus Regeln neue Fakten 
abzuleiten und, falls dies nicht mehr möglich ist, neue Fakten von dem Benutzer 
zu erfragen. Die dem Inferenzmechanismus zugrundeliegenden prädikatenlogischen 
Gesetze sind sehr allgemein, z.B. modus ponens (Wenn "A" gilt und es gilt "aus A 
folgt B" dann leite "B" ab). Der Inferenzmechanismus repräsentiert das allgemeine 
Problemlösungswissen im Gegensatz zum speziellen Problemlösungswissen, welches 
in den Regeln der Wissensbasis abgelegt ist. Weiterhin ist es möglich, auf die 
Angabe von Kontrollinformation im Wissenseditor zu verzichten, wenn es eine 
klare Trennung zwischen Wissensbasis und Inferenzmechanismus gibt. Der Leit- 
gedanke, der hinter dieser deklarativen Programmierung steckt lautet: sage WAS 
gemacht werden soll, nicht WIE! 

Der Benutzereditor ist die Schnittstelle des Expertensystems zur 
Außenwelt, über diesen Editor erhält das System neue Informationen vom 
Benutzer oder den Sensoren. Da der Benutzereditor sich zumeist an einen uner- 
fahrenen Adressaten wendet, ist hier auf einfaches Design, leichte Verständlichkeit 
und Handhabbarkeit Wert zu legen. 

Die Erklärungskomponente hilft dem Benutzer, die "Überlegungen" des 
Systems zu verstehen. In den meisten Fällen wird auf Anfrage erklärt, welche 
Inferenzen gemacht wurden, welches Wissen momentan bekannt ist (bisherige 
Hypothesen) und warum eine bestimmte neue Frage gestellt wurde. Die Absicht 
ist die geistige Einbeziehung des Benutzers in den Inferenzmechanismus. Dadurch 
ist es häufig möglich, Verständnisschwierigkeiten zu vermeiden oder vielleicht den 
Dialog vorzeitig zu beenden, da der Benutzer die Lösung des Problems bereits 
sieht. 




3. 



Prototyp zur .Diagnose-an. C N C-Maschinen 



Zur Evaluation des praktischen Nutzens eines Diagnosesystems wurde in 
Zusammenarbeit mit einem Drehmaschinenhersteller ein Prototyp entwickelt. 
Hierbei wurde besondere Aufmerksamkeit auf die Integration in die 
Arbeitsumgebung sowie auf die Probleme des Benutzers bezüglich Handhabbarkeit 
und Akzeptanz gelegt. 

Es zeigte sich, da/? die allgemeine Architektur eines Expertensystems um 
eine weitere Komponente, den Wissenscompiler, erweitert werden mußte . Seine 
Aufgabe besteht in der Portierung des durch den Experten auf der Entwicklungs- 
umgebung eingegebenen Wissens auf die Zielumgebung. 
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Bild 4: Architektur des Prototypen zur CNC-Maschinen Fehlerdiagnose 

Wie Bild 4 zeigt, wurden zwei verschiedene Expertensysteme geschaffen: 

(1) Die LISP-Version dient dem Experten als Werkzeug zur Eingabe sowie 
zum Testen des Wissens. In der Testphase ist der Benutzer des Experten- 
systems der Experte selbst. 

(2) Die C- Version dient den Maschinenbediener/Servicetechniker als reines 
Expertensystem. Dieses ist in die CNC-Maschine integriert. Änderungen 
in Fakten- bzw. Regeldefmitionen sind hier nicht möglich. 
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Die folgende Liste zeigt einige Vorteile dieser speziellen Systemarchitektur. Dabei 
erfüllt der Prototyp diese Vorteile nicht vollständig, sondern teilweise beziehen sie 
sich auf ein ausgereiftes Expertensystem, das in dem folgenden Abschnitt vor- 
gestellt wird. 

Die Entwicklung der Wissensbasis erfolgt beim Hersteller. Es muß nicht 
nur eine große Datenmenge erstellt werden, sondern auch gepflegt und 
auf den neusten Stand gebracht werden. Dazu sind Informationen nötig, 
die nur beim Hersteller zusammenfließen. 

Der Maschinenbediener/Sevicetechniker hat keinen Einfluß auf die 
Wissensbasis, selbst wenn er einen Maschinenfehler findet, der nicht im 
Expertensystem enthalten ist. Hierzu müßte er den Aufbau, den Formal- 
ismus und die Funktionsweise des Expertensystems kennen. Es ist 
kostengünstiger und effizienter, einen zentralen Experten zu beschäftigen, 
der neu gewonnene Informationen ins System einfügt. 

Das Expertensystem benötigt hardwaremäßig lediglich Speicherplatz. 
Hier liegt ein Hauptvorteil der Reimplementation: es sind keine 
kostspieligen, neuen Computer nötig, um das Expertensystem anzuwen- 
den. 

Wird das Expertensystem beim Hersteller verbessert oder wird die 
CNC-Maschine z.B. durch Peripheriegeräte verändert, so brauchen nur 
EPROMS für die aktuelle Version verschickt und ausgetauscht werden. 
Auf diese Weise kann das Expertensystem leicht aktualisiert werden und 
entspricht so dem aktuellen Wissensstand. 

Dem Hersteller bringt das durch das Expertensystem gesammelte und 
durch den Formalismus standardisierte Wissen Vorteile. Z.B. sind auf 
diese Weise Schwachstellen von Maschinenteilen bzw. Baugruppen 
leichter erkennbar und können evtl, behoben werden. Gegebene 
Voraussetzung hierfür ist natürlich, daß der Hersteller selbst das Exper- 
tensystem entwickelt und verbessert. 

Das System besteht aus 460 Regeln und 110 Regelknoten. Es existieren 122 Fak- 
ten mit möglichen Fehlermeldungen, wobei es sich bei 9 Fakten um Sensoren han- 
delt. Üblicherweise wird je ein weiterer Fakt aus den Sensoren abgeleitet, so daß 
ungefähr 20 Fakten zu Beginn der Diagnose bekannt sind. Der Benutzer muß 10 
bis 20 Fragen beantworten bis das System ein Ergebnis erzielt. Ziel des Proto- 
typen war eine schnelle Implementation zur Aufdeckung seiner Möglichkeiten. Die 
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Entwicklungszeit betrug ungefähr ein halbes Mannjahr. Das System ist in die 
Maschinensteuerung integriert und benötigt etwa 100 K Speicherplatz. Der Proto- 
typ deckt mit 15% der möglichen Fehler etwa 50% der Fehlerquellen ab, die in 
einem festen Zeitintervall auftreten. 

Das Diagnosesystem benötigt keine aufwendige Hard- und Software, da 
es die existierenden Ressourcen der CNC Maschine ausnutzt. Allerdings hat der 
einfache Aufbau auch seine Nachteile, besonders bei der Erweiterung der 
Wissensbasis. Der Hauptnachteil liegt in der Einbettung des Inferenzmechan- 
ismusses in die Regelmenge. Aufgrund der Regelknotenstruktur ist der Wissen- 
singenieur gezwungen, sowohl die Regeln als auch ihre Kontrolle zu 
berücksichtigen. 
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4 . Expcrteraystemtool 2 ur Diagnose an CNfcMaschinen 

Die Erfahrungen mit den Prototypen haben einerseits die gute Verwend- 
barkeit von regeibasierten Systemen zur Diagnose bewiesen. Andererseits sind 
beim Testen einige Nachteile aufgetreten, die vor allem den Formalismus des Sys- 
tems betreffen. 

Außer der Bearbeitung von Fehlern, die der Bediener selbst leicht behe- 
ben kann, soll das Expertensystem auch folgende neue Forderungen erfüllen: 

Expertensystem für mehrere Maschinentypen und leichte 
Übertragbarkeit von Fakten und Regeln bei gleichen Maschinenkom- 
ponenten. 

Berücksichtigung von "Umwelteinflüssen" wie Standort und Alter der 
Maschine sowie Daten über Wartungsmaßnahmen, d.h. Speicherung und 
Verarbeitung von Daten, die über eine reine Diagnose hinaus gehen. 
Anleitungen für Instandsetzungsarbeiten eines Servicetechnikers, d.h. 
Tests durch Veränderungen bzw. Ausbauen von Maschinenteilen soll 
möglich sein. 

Mehr Flexibilität bei der Verfeinerung oder Veränderung des Wissens. 
Diese neuen Forderungen führen nicht nur zu quantitativen Veränderungen, son- 
dern vor allem zu qualitativen Systemveränderungen. Es ergibt sich ein völlig 
neues Expertensystem, welches in den folgenden Abschnitten erklärt wird. 
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4.1. Wissftnsha.sis 

Die Wissensbasis ist weitaus differenzierter als die des Prototyps. Der 

grundsätzliche Aufbau der Wissensbasis ist folgender: 

(1) Die Faktdefinition wird unterschieden in Maschinenteilname, Eigen- 
schaftsname dieses Teils. Durch die Zweiteilung des Namens ist eine 
klarere semantische Unterscheidung möglich. Der Maschinenteilname 
bezeichnet eindeutig den Ort an der Maschine und die Eigenschaft dieses 
Teils bezeichnet das Symptom, welches beobachtet bzw. gemessen wer- 
den soll. Ein Maschinenteil kann mehrere Eigenschaften besitzen. 

(2) Die Faktdefinition wird um Attribute erweitert. Die Attribute enthalten 
Informationen, die im Prototypen teilweise innerhalb der Regelstruktur 
enthalten waren und teilweise neu sind, um detailliertere Definitionen 
und Ableitungen machen zu können. Der Vorteil dieser Faktattribu- 
tierung ist der, da/? die Informationen aus der dynamischen Regelstruk- 
tur in die statische Faktstruktur transformiert werden. 

(3) Die Regeldefinition wird vereinfacht. Die Vorbedingungen und Fol- 
gerungen dürfen nur noch mit UND verknüpft werden. Die einzelnen 
Regeln sind voneinander unabhängig und brauchen nicht untereinander 
in eine Struktur für den Inferenzmechanismus eingefügt werden. 



4.2. Wissenseditor 

Grundsätzlich ist zum Verhältnis des Wissenseditors und der 
Wissensbasis zu sagen, da/? beide Darstellungen strukturell gleich sind. In der 
Wissensbasis erfolgt lediglich eine Codierung einiger Werte. Die wesentlichen 
Charakteristika des Wissenseditors sind folgende: 

(l) Für den Wissensingenieur werden Fakten und Regeln strukturiert, um 

die Übersicht zu erhöhen. Die Maschinenteile sind nicht zusammenhang- 
los, sondern sind vom obersten Knoten "Maschine" baumartig aufgebaut. 
Die Menge aller Söhne zu einem Knoten ist die Menge aller Unterteile 
und wird in dieser Form auf dem Bildschirm angegeben (Browser). Auf 
diese Weise kann der Experte einzelne Teile und deren Eigenschaften 
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über eine gewohnte Struktur finden. 







Bild 5: Eigenschafts- und Regeldefinition des Wissenseditors 

Alle dem Wissensingenieur zugänglichen Informationen und Funktionen 
werden in Fenstern und Menüs gehalten. Die Verwendung von Fenstern 
und Menütechnik erleichtert dem Wissensingenieur einerseits die 
Bedienung des Expertensystems, denn die möglichen Funktionen werden 
in Menüs zur Auswahl gestellt, und andererseits die Übersichtlichkeit, 
indem logisch zusammengehörige Informationen in Fenstern bzw. Unter- 
fenstern partitioniert sind. Außerdem verhindert das Selektieren von 
Symbolen und auch das Auswahlen von vorgegebenen Wert mengen aus 
Menüs syntaktische Fehler. 

Alle Attribute der Fakten und Regeln werden mit Default-Werten vor- 
belegt, sobald eine Eigenschaft bzw. eine Regel definiert wird. Hierdurch 
wird der Experte in seiner Arbeit etwas entlastet, denn er braucht nur 
noch die falschen Attribute ändern. Außerdem ist es über ein Optionen- 
fenster möglich, die einzelnen Attribute auszublenden, so daß sich der 
Experte z.B. in der Einlernphase auf die wichtigsten Eingaben 
beschränken kann. 
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4.3. Merenzmechanismiis 




Bild 6: Schema des Inferenzmechanismus 

Die Regeln werden nach einer Forward- Ableitungsstrategie bearbeitet. 
Eine Backward- Ableitungsstrategie wie in PROLOG ist nicht sinnvoll, da es keine 
Fragen oder vorgegebene Ziele gibt, die bewiesen werden müssen. 
Ableitungsschema ist modus ponens. Der gesamte Inferenzmechanismus läuft nach 
folgendem Schema ab: 

Die Kontrolle des Inferenzmechanismus wird von einer Heuristik 
übernommen. Vorteil der Heuristik ist, da/? sie einen automatischen Proze/? dar- 
stellt, der nicht vom Experten gesteuert werden braucht. Ziel der Heuristik ist das 
Finden einer guten Frage bzw. das Erreichen einer guten Antwort. Um den Erfolg 
einer Frage abzuschätzen, besteht die Gesamtheuristik aus Einzelheuristiken, die 
gewichtet und aufsummiert werden und so die Gesamtheuristik ergeben. 

Einzelheuristiken sind: 

Kosten für die Beantwortung der F rage: 

Kostenfaktor ist hauptsächlich die Zeit. So kann man z.B. die Tempera- 
tur des Motors sehr schnell nachschauen, wohingegen die Abnutzung der 
Kohlebürsten im Motor nur durch umfangreiche Ausbauma/?nahmen 
nachschaubar ist. 

Fehlerhäufigkeit: 

Z.B. tritt ein Fehler in der Motortemperatur relativ häufig auf, zu stark 
abgenutzte Kohlebürsten sind sehr selten. 

Evidenzheuristik: 

Falls in einer Regel mit mehreren Vorbedingungen schon eine oder 
mehrere beantwortet sind, werden die noch unbekannten Vor- 
bedingungen als Fragen bevorzugt. Implizit setzt diese Heuristik einen 
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funktionalen Zusammenhang zwischen den Vorbedingungen voraus. 
Diese Heuristik garantiert, da/? ein Weg zu einem Fehler verfolgt wird. 

T ransistivitätsheuristik: 

Ein indirekter Informationsgewinn ergibt sich dadurch, da/? eine oder 
mehrere Antworten durch eine Regel einen neuen Fakt setzen können. 
Dieser neue Fakt kann selbst wieder eine Vorbedingung in anderen 
Regeln sein und so weitere Fakten setzen bis hin zum Fehler. Diese 
Transitivität wird bewertet. 




Bild 7: Verwendung der Heuristikfunktion 
Erklärungen zu Bild 7: 

Jeder Knoten im Baum repräsentiert das gesamte Wissen über die 
C NC-Maschine. 

Die Wissensbasis repräsentiert genau einen Knoten im Baum. 

Für die Heuristik sind alle unbekannten Eigenschaften wichtig. 

Die Gesamtheuristik berechnet numerisch die Güte aller Söhne zu dem 
bestehenden Wissen. 

- Der Übergang zwischen zwei Knoten repräsentiert die Beantwortung 

einer Frage. 
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Die interne Darstellung muß nicht explizit alle Söhne der gegebenen 
Wissesbasis generieren, sondern es genügt eine Zuordnung eines Heuris- 
tikwertes zu jeder Eigenschaft. Jede unbekannte Eigenschaft enthält die 
Einzelheuristiken sowie die Gesamtheuristik. 

Durch die Heuristikfunktionen, speziell die Transivitätsfunktion, geht in 
den Heuristikwert nicht nur Information über die Güte der Beantwor- 
tung der nächsten Frage ein, sondern auch Information über weitere 
F ragen. 

Heuristiken garantieren im allgemeinen nicht das Finden optimaler Fragen bzw. 
das Generieren eines optimalen Pfades der Ableitungen bis hin zum Fehler, jedoch 
können die Einzelheuristiken verbessert werden, indem sie von den Unsi- 
cherheitsfaktoren abhängig gemacht werden. 

Bei allen Ableitungen werden die den Eigenschaften bzw. Regeln 
zugeordneten Unsicherheitswerte berücksichtigt. Als Berechnungsschema für Unsi- 
cherheitsfaktoren verwenden wir ein rein probabilistisches Konzept. Die aktuellen 
Unsicherheitswerte der mit AND verknüpften Bedingungen werden multipliziert 
und in Relation zur statischen Unsicherheit der Regel zum aktuellen Unsi- 
cherheitswert der Folgerung addiert. Bild 8 zeigt ein Beispiel. 




Bild 8: Berechnung der Unsicherheitswerte 



4 . 4 . 



Benutzereditor und Erk lärungskom ponen te 
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Der Benutzereditor ist die Schnittstelle des Expertensystems zur 
Außenwelt, über diesen Editor erhält das System neue Informationen vom 
Benutzer oder den Indikatoren. Die Indikatormeldungen werden am Anfang des 
Dialogs abgefragt. Der Dialog des Systems mit dem Maschinenbediener ist 
meniigesteuert. Auf dem Bildschirm stehen etwa die letzten 10 Fragen und 
Antworten. Der Dialog mit dem Benutzer wird durch die vom System gestellten 
Fragen bestimmt, die Antworten werden über variabel belegbare Funktionstasten 
gegeben. 

Da der Benutzereditor auf dem Zielsystem mit den existenten Soft- und 
Hardware Bedingungen auskommen soll, gibt es nur eine minimale 
Erklärungskomponente. Einerseits existiert eine Anzeige der vermuteten Fehler, 
welche gewährleisten soll, daß dem Benutzer die Ursachen und die Absichten der 
gestellten Fragen verständlich werden. Andererseits hat er die Möglichkeit, Vermu- 
tungen zu äußern, um den Diagnoseprozeß in die von ihm gewünschte Richtung 
zu steuern. 

Zusammenfassend ist festzustellen, daß das hier vorgestellte Expertensys- 
temtool noch nicht vollständig implementiert ist, und daß sich die Tauglichkeit 
des Systems erst noch in umfangreichen Tests erweisen muß. Das Gesamtkonzept 
löst allerdings alle gestellten Anforderungen bis hin zur betrieblichen Integration. 
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CONDITIONS ON A KNOWLEDGE REPRESENTATION FOR 
PROCESSING NATURAL LANGUAGE SEMANTICS 

Gerhard Heyer /Bernd Schneider 
TA Triumph-Adler AG, Nuernberg 



Zusammenfassung 

Anhand eines Beispiels werden zunaechst minimale Anforderungen an eine 
Wissensrepraesentation bei der Verarbeitung der Semantik eines Textes 
diskutiert. Wir stellen sodann eine Erweiterung von PROLOG auf der 
Grundlage des KL-ONE Ansatzes vor, welche die gestellten Anforderungen im 
wesentlichen erfuellt und neben der Konstruktion unvollstaendiger Objekte 
mit Hilfe eines epistemischen Levels und einer Unterscheidung 
verschiedener Praedikate insbesondere auch die Integration von 
konzeptuellem und funktionalem Wissen gestattet. 

Schluesselwoerter: 

Wissensrepraesentation, Verarbeitung natuerlicher Sprache, Wissens - 
akquisition 

1. Introduction 

The following paper discusses by way of an example minimal requirements 
on a knowledge representation for processing natural language 
semantics, and presents in outline the basic architecture of an extension 
of PROLOG that meets the proposed requirements. The system has been 
developed within the ESPRIT project ACORD, a natural language system 
that aims at the construction and interrogation of knowledge bases within 
the area of so-called business communications using natural language text 
and graphics. A detailed scenario for a possible application of the 
system within the area of logistics and the transport business is given 
below. Depending on whether or not a knowledge base has already been 
defined, the ACORD system can be regarded either as a general natural 
language interface, supported by graphics, to expert and decision-support 
systems, or as a general tool for constructing a knowledge base that 
can subsequently be interrogated by one or several users. Given the 
restricted aims of the system, it is not designed to model human language 
comprehension, or advocate a particular view of what it means to 
understand language (cf. WINOGRAD 1980). 

The knowledge representation we propose can either be called directly by 
the output of the parser module as the semantic representation language 
and the interpreting model of the natural language input, or by a 
mediating semantic representation language, such as DRS, whereby it would 
function as the interpreting model of the natural language input by 
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providing an interpreting model of its semantic representation. 

Although there are good reasons for ultimately identifying the 
representations of meaning and knowledge (HABEL 1986:29), the ACORD 
system distinguishes between the level of semantic representation, using 
DRS as semantic representation language, and the level of the knowledge 
base expressed in terms of our knowledge representation language. 

2. Requirements on the Knowledge Base 

The system aims at being able to read in a small text on the sample 
application domain, to add the information to the knowlege base, and to 
retrieve information from that knowledge base upon request. Consider, for 
example, the following piece of update of a knowlege base on available 
resources in a transport business: 

(1) None of the trucks are at their place of registry. 

(2a) Truckl is going from Munich to Berlin, (b) It is 
carrying peripherals. (c) It will arrive in Berlin 
at 5 o'clock. 

(3a) Truck2 is staying in Cologne, (b) It is unloaded. 

(c) It has a loadcapacity of 10 tons. 

(4a) Truck3 is on the way to Nuremberg carrying a 
load of personal -computers. ( b) I t has been laying in 
Frankfurt since 8.30 with a defunct engine. 

(5a) Tankerl is transporting 500 hectoliters of wine to 
Frankfurt, (b) It is coming from Florence. 

Upon request, the system should be able to answer questions concerning 
the described situation, e.g. it should be able to answer questions like 
"What is truck2 carrying?", "When and where does truckl arrive?", or 
"Does truck3 have a broken engine?". Moreover, the system should be able 
to answer questions that require a certain amount of reasoning or 
reflection, like "Can tankerl transport peripherals?", or "How much 
freight can truck2 carry?". 

The amount and kind of background knowledge required for such reasoning, 
as well as the kind of inferences involved, certainly vary from the 
specific tasks that may be posed. Thus, somebody interested in the 
analytic structure of the information given might be interested in 
knowing whether truckl can be said to move, whether the movement of 
truckl describes a four-dimensional space-time trajectory, or whether the 
movement of truckl is causally responsible for it eventually reaching 
Berlin. The line of what the system is supposed to know about the world, 
physics, or our knowledge about the world is difficult to draw (cf. 
DREYFUS 1985, SEARLE 1984). For our purposes we assume this to be a 
practical decision hinging on the particular use that the system is being 
put to. Thus, while the system should know that a freight does not 
move by itself, and that, therefore, the load of personal -computers that, 
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e.g., truck3 is carrying will not arrive in Nuremberg on their own, it 
need not know anything about the population of Nuernberg, or that every 
truck has a colour. 

In general, answering a question will therefore first require an 
evaluation of the relevance of the question. For the present purposes, 
however, we will simply delimit the set of questions that possibly can be 
asked. The following is an attempt to structure the set of possible 
questions in an intuitive manner on the basis of their semantics. 

We first devide questions into three basic categories : 

-inverted questions (asking for a truth-value) 

-pronominal wh-questions (asking for a value 
of some individual variable) 

-sentential wh-questions (asking for the value 
of a sentential operator variable) 

Within each type of question a number of further distinctions hold that 
we exemplify for simplicity's sake only in the case of inverted 
questions. 

Assuming now the imagined update, three basic kinds of questions can be 
distinguished: 

I) Querying of facts 



e.g. "Does truckl carry PCs from Munich to Berlin?" 

II) Querying of parts of facts 



e.g. "Does truckl carry PCs?" 

Ill) Querying of derived facts 



The latter category really is quite complicated and requires further 
subdivisions. Although arguable, it seems convenient to distinguish 
between facts derived on grounds of logic and facts derived on grounds of 
world knowledge. For each kind of derived fact a number of questions 
can now be asked that we present here with respect to nouns, verbs and 
prepositions : 

a) facts derived on grounds of logic 



1) presuppositions 

noun: "Does a truck carry PCs from Munich to Berlin?" 
verb: "Does truckl exist?" 

prep: "Is it true that Munich is not the same place 
as Berlin?" 
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2) isa-generalization 

noun: "Does a vehicle carry PCs from Munich to 
Berlin?" 

verb: "Does truckl transport PCs from Munich to 
Berlin?" 

3) semantic roles 

i) unfilled (default roles) 
noun: "Is a driver driving truckl?" 

"Does truckl have a destination?" 
prep: "Are the PCs on truckl?" 

"Is the wine in the tank of tankerl?" 

ii) filled 

noun: "Is Munich the place of departure of truckl?" 
verb: "Does truckl depart in Munich?" 

4) components 

noun: "Does truckl have a loadcapacity?" 

5) relational implicatures 

prep: "Is truckl under the PCs?" 



b) facts derived by world knowledge 



1) based on knowledge about places 

e.g. "Does truckl go on the A9?" 

"Does truckl pass through Nuernberg?" 

2) based on knowledge about spatial relations 

e.g. "Is the trailer behind the truck?" 

Most of these types of questions reappear within the categories of 
pronominal- and sentential wh-questions. Within the category of 

pronominal wh-questions it has to be recognized that in German certain 
prepositions call for particular questions particles, e.g. "mit" for 
"womit", "von" for "woher", and "nach" for "wohin". In English the 
prepositions just reappear within the wh-question, e.g. "where from", 
"where to", "what with" etc. 

Considering the piece of text and the questions presented above, we can 
derive the following requirements on a knowledge base that is to process 
this text. 
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(i) The knowledge base must allow for an incremental construction, as the 
input information is provided sentence by sentence. 

On the one hand, objects introduced into discourse may require a 
subsequent emendation or modification. As is apparent from clauses 
(3a), (3b) and (3c), the introduction of an object named "truck2", gives 
rise to a specification of further properties that are asserted of this 
object and that need to be added to its object-frame. The need for a 
modification of properties of an object is evident from clauses (4a) and 
(4b): while it is reasonable to assume by default that every truck has an 
engine that works, the object with the name "truck3" , introduced into 
discourse by clause (4a), does not have a working engine in the given 
situation, as is stated by clause (4b). 

Moreover, it may be necessary to also add further specifications on facts 
that already have been asserted during the previous discourse. As is 
illustrated by clauses (2a), (2b), and (2c), there may be a simple fact 
like "Truckl travels" that may be further specified in various regards: 
that the travelling takes place from Munich to Berlin, that it is 
accompanied by the carrying of peripherals, and that it will terminate in 
Berlin at 5 o'clock. This observation corresponds to the intuitive 
distinction, broadly accepted in linguistic thought, between obligatory 
arguments of the verb and its facultative complements (DUDEN 1984). 

(ii) The knowledge base must allow for an integrated representation of 
conceptual and functional knowledge. Apart from simple conceptual 
hierarchies as they are commonly provided by an "isa"-net, more 
interesting forms of background knowledge involve functional 
specifications, - e.g. something is a truck if it is a vehicle for 
transporting goods travelling on road - , or an integrated specification 
of function and conceptual structure, as seems to be required for the 
specification of what it means to be a tanker, viz. being a truck that 
has as component a tank for transporting liquids. 

(iii) Moreover, as is evident from clause (1), the knowledge base must 
also allow for the resolution of quantified sentences. In fact, 
quantified sentences represent a particular problem for the processing of 
natural language semantics, as it requires efficient proof procedures, 
and, in the case of generalized quantifiers (BARWISE/COOPER 1981), even 
goes beyond standard first order predicate logic. 

(iv) In order to allow for an efficient information retrieval, the 
knowledge base must also contain linguistic knowledge, basically 
knowledge about synonyms (within the intended domain of application), as 
is evident when we consider queries like "Where is truckl going to?" that 
is to be understood as "Where does truckl travel to?". 




3. A Brief Survey of Knowledge Representation Languages 



Although a number of knowledge representation languages have 
explicitly been designed for natural language processing, including, 
amongst others, KRL (BOBROW/WI NORAD 1977), KL-ONE (BRACHMAN/SCHMOLZE 
1985), and KL-TWO ( VILAIN 1985), none of the commonly available systems 
sufficiently adress to our knowledge the issues raised above. Rather, 
they focus on a number of detailed problems, each of which undoubtedly is 
relevant for processing natural language semantics, but insufficient as a 
single, general principle: prototypes and frames, structured inheritance 
networks and generic objects, the role of epistemological primitives, the 
distinction between terminological and assertional knowledge, or the 
distinction between propositional and quantif icational reasoning. 

Considering the complexity of natural language, we cannot but conclude 
that no single representation principle will be fully adequate for 
processing natural language semantics. Thus, there is a strong argument 
for hybrid systems such as KRYPTON. Considering the well known trade-off 
between knowledge representation and reasoning (LEVESQUE/BRACHMAN 1985), 
the trick here is to factor the reasoning task into a theorem prover 
(able to deal with first order predicate logic) and a description 
subsumption mechanism both of which can be seperately called. However, 
given that full first order predicate logic is only semi decidable, and 
that even the best theorem provers are prone to time consuming search, 
there is good reason to consider systems that only comprise decidable 
subsets of first order predicate logic such as Horn clause logic (cf. 
McAllester 1980 and 1982). 

What we need, therefore, is a representation language that on the one 
hand need only be based on a decidable subset of first order predicate 
logic, but on the other is rich enough to meet all of the above requests 
for processing natural language semantics. 

For the following we will consider PROLOG a suitable and efficient 
language to achieve this aim. In fact, a number of natural language 
processing systems do use PROLOG as the semantic representation language, 
e.g. WALLACE (1984), HELLISH (1985), or Borland's TURBO-PROLOG natural 
language query system GEOBASE. However, all of these systems are natural 
language query systems, and no one is suitable, nor has been designed, 
for a construction of a knowledge base using natural language. Hence, 
none of the systems provide for a distinction between background 
knowledge and the actual information being asserted, or between 
functional and conceptual knowledge. As the representation language that 
these systems use just is PROLOG, the representation of different kinds 
of knowledge neither is supported nor available. 

In what follows we will attempt to define an extension of PROLOG 
(programmed in PROLOG) that avoids these shortcomings and promises to 




- 140 - 



serve as a fruitful tool in the processing of natural language semantics. 

4. The Basic Architecture 

Following a longer logical and linguistic tradition, the goal of a 
knowledge representation for natural language can be defined as follows: 
what we are looking for is a representation of natural language sentences 
such that as many as possible intuitively valid inferences are verified, 
and as many as possible intuitively invalid inferences are falsified. (For 
the present, we will restrict ourselves to the kinds of questions 
presented above). 

Before laying down the basic architecture of our knowledge 
representation, and specifying in detail the functions by which it is 
realized, it is instructive to compare the extension of PROLOG that we 
propose with the role of first order predicate logic for the semantic 
analysis of natural language. As has been demonstrated by the 
logico-linguistic discussion of the seventies on Montague-Grammar, there 
are in principle two strategies for the logical analysis of natural 
language: if first order predicate logic is to be used as the semantic 
representation language, then it is necessary to specify comparatively 
complex translation-rules for translating natural language sentences into 
predicate logic, due to the conceptual distance that predicate logic 
bears to natural language; if we want to keep the translation-rules as 
simple and transparent as possible, then it is necessary to enrich first 
order predicate logic by additional expressive power that brings it 
closer to the syntax and semantics of natural language expressions 
(Montague's 'intensional logic' is a second order predicate logic 
amended with intensional and modal operators (MONTAGUE 1974)). Taking up 
the latter alternative without actually increasing the expressive power 
of PROLOG, what we gain by extending PROLOG is a more transparent 
system that can be better tuned to the output of the parsers, than if we 
just used PROLOG proper. The difference concerns the task of the dialogue 
manager: within the proposed system the translation of DRSs into 
expressions of the knowledge base is very straightforward and presents no 
serious difficulties (HEYER/SCHNEIDER/KESE 1986a). 

With regard to the requirements on a knowledge representation for 
processing natural language semantics posed above, the basic ideas of the 
system are as follows: 

(i) We treat of the incremental construction of objects and facts by 
defining an 'epistemological' level, i.e. we define a set of 
underlying object and relation types for knowledge structuring 
(cf.BRACHMAN 1985:176) as a special level in between PROLOG as the 
implementational level and the complete object-descriptions and facts on 
the conceptual level. Thus, in the course of an update, object frames and 
facts can be created that only successively are filled and completed. 
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Moreover, the conceptual level is being realized by functions of the 
epistemological level . 

(ii) Conceptual knowledge is being provided for by adding to PROLOG a 

set of functions that realize an object-oriented extension (without 
'message passing'), or a 'structured inheritance network 1 . Thus, we 
define on the epistemological, as well as on the conceptual level a 
number of functions that allow one to distinguish between classes and 
their instances, order classes in a supremum semi-lattice, define 
components, properties, and kinds of classes, and define and evaluate how 
these components and properties are to be inherited. As these functions 
are PROLOG terms, they can be easily mixed with other PROLOG terms that 
are used to represent functional dependencies or simple facts. Apart from 
the integeration of the conceptual and functional dimension, our 
extension of PROLOG contains object-attribute-value triples embedded in a 
isa-hierarchy, it allows for cross-classifications by defining 
dispositions of objects, and it provides a default inheritance for 

components, kind, and dispositions. 

(iii) Quantification and facts will be treated by PROLOG. As concerns 
quantification, this implies a restriction to Horn clause logic; however, 
as we will see, the addition of meaning postulates by which a negation 
appearing in the head of a PROLOG clause can be avoided, provides a way 
by which this restriction of Horn clause logic can be avoided in most 
cases. For the representation of facts, we introduce into PROLOG a 
distinction between three different types of facts: dispositions, events, 
and general states of affairs (see below). A fact can then be asserted 
as a PROLOG fact using the proposed types of predicates. 

(iv) Linguistic knowledge, in particular the definition of synonyms and 
the reduction of complex terms to a set of primitive terms, simply 
exploits PROLOG; it has not been necessary to add a module that 
exclusively deals with this kind of knowledge. 

5. Notes on the Implementation 

To represent conceptual knowledge related to nouns and verbs, we use 
so-called 'deep-frames' for the construction of object- and 
property-frames. Every frame is uniquely identified by its identifying 
name (ION). No two frames have the same name; if a frame is called by a 
name that already exists, either the old frame is overwritten or the name 
of the new frame is made unique by adding some postscript. 

Associated with every object or property is a frame that carries the 
following information: 
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FRAME 



ION (name) 



NAME 



COMPONENTS 



ISA 



SPECIALIZATION 



KIND 



OBJECT TYPE 



USEDIN 



CLASS 



SUPERCLASSES 



INSTANCES 



PROTOTYPES 



AFFAIRS 



BEQUEATH_COMPS 
INHERIT COMPS 



BEQUEATH_AFFAIRS 



As an example consider the following sample frames for "vehicle" and 
"drive" : 



Object- and Property-Frames 

frame([[ ion, vehicle] , 

[name] , 

[components] , 

[ i sa,means_of_transport] f 
[specialization, lorry] , 

[kind, individual] , 

[objectjtype, class], 

[class], 

[ superclasses, meansjDf_transport, 
countables , 

phys i ca l_ob ject , object , 
non_tempora l_ent i ty , ent i ty ] , 
[usedin, drive, 

serve, stop, 
arrive, go, 
come] , 

[instances], 

[prototypes], 

[affairs] , 

[bequeath_comps] , 

[ inherit_comps] , 
[bequeath_affairs]]) . 
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frame([[ ion, drive], 

[name], 

[components , [agens , driver] , 

[ i nstrument , veh i c le] , [pat i ens , unknown] , 

[source, departure] , [goal destination] , 

[benef akt i v , unknown] , [path , unknown] ] , 

[isa, transport] , 

[spec i a 1 i zat i on , serve , 
stop, arrive, 
go, come] , 

[kind, property], 

[object_type, class] , 

[class], 

[superclasses , transport] , 

[usedin], 

[instances], 

[prototypes] , 

[affairs] , 

[bequeath_comps, [agens, driver] , 

[ i nstrument , vehicle] , [ pat i ens , unknown] , 

[source, departure] , [goal »destination] , 

[benef akt i v , unknown] , [path , unknown] ] , 

[ i nheri t_comps , [agens , animate_bei ng] , 

[ i nstrument ,means_of_transport] , [patiens , unknown] , 
[source, unknown] , [goal , unknown] , 

[benef akt i v , unknown] , [path , unknown] ] , 
[bequeath_affairs]]) . 



ION is the identifying name of the frame, as explained above. If a frame 
is known under a different description, it can also be given a NAME 
different from its ION, however, the frame will always be accessed only 
by its ION. In the present version, there is as yet no way to express 
identities . 

Properties that one wants to hold of a frame necessarily relative to a 
particular domain of application are called its COMPONENTS. Within the 
underlying ontology, COMPONENTS are themselves frames. Any frame can be 
assigned a certain KIND: either 'individual 1 , 'mass', or 'abstract' 
for objects (in the usual sense of these notionse, cf. CHOMSKY 1967), and 
'property' for properties. Hence, a COMPONENT need not be strictly a 
physical part of some other frame (like "motor" of "truck"), it can also 
be abstract (like "load-capacity" of "truck"). A frame is assigned a 
COMPONENT by using the function "link_as_component" of the epistemic 
level, or by defining the COMPONENT when defining the class. The slot 
USEDIN records of a frame in which other frames it is used as a 
component. A COMPONENT is a pair consisting of a component name and a 
value; the value of a component of a class is a class, the values of 
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components of instances are instances. These "component instances" must 
either be instances of the corresponding "component class frames", or 
instances of classes that are specializations of the component class 
frames. The notions of CLASS and INSTANCE correspond to Brachman's 
notions of 'concepts' and 'individuals' (BRACHMAN 1985). PROTOTYPES 
can be regarded as classes the components of which have been assigned at 
least one particular value; if all components of a PROTOTYPE have been 
assigned particular values, then by definition the PROTOTYPE is 
considered a CLASS. However, for most practical purposes it suffices to 
simply use classes and instances. However, the distinction between 
classes, instances, and prototypes only pertains to object-frames, i.e. 
property-frames allow for classes but do not have instances and 
prototypes. Thus, a frame's being a class, prototype, or instance is 
considered its OBJECT_TYPE. 

Every frame of the structured inheritance network is part of a supremum 
semi-lattice defined by the ISA relation defined in the usual way 
(BRACHMAN 1985). SPECIALIZATION is the converse of ISA. SUPERCLASSES 
records the transitive closure of ISA. 

Most properties of a frame are specified by way of the function 
"create_nst_affair" of the epistemic level, or simple PROLOG predication. 
AFFAIRS records the state-of-affairs that a frame is involved in, i.e. it 
records the predicates that apply to the frame. 

Components and certain predicates (viz. so-called dispositions) defined 
for a class will in general be inherited down to its specializations 
and instances. Properties and components that are not to be passed on are 
to be excluded by the function " 1 ink_as_private" of the epistemic level. 
To prohibit inheritance from a superclass, the function 
"exclude_from_superclass" of the epistemic level has to be called. The 
slots BEQUEATH_COMPS and INHERIT_COMPS record the components that are 
passed on resp. inherited from a class. BEQUEATH_AFFAIRS records the 
properties that are passed on from a class. (The properties that are 
inherited from a frame are listed in AFFAIRS). Given a specification 
of default properties and components, the inheritance relations can under 
certain circumstances be modified. 

5.1 Affairs 

To describe accidental or necessary characteristics of objects, or 
connections between objects (if these are not generalization-, 
specialization-, class-prototype-instance- or component- relations), one 
can define affairs. The characteristics of an object, resp. the 
connections between objects, are described as a property of the 
object/objects. 

Mathematically viewed, affairs are n-ary (n>0) relations between objects. 
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The involved objects can also be called parameters of the affair. In 
contrast to objects, an affair is not individual, i.e. there exists no 
different affairs with the same property, the same arity and identical 
objects. Only the so called general affairs are invalidable. 

Affairs always have a type that defines : 

- with which type of object the affair can be generated, 

- when the defined affair can be invalidated, 

- when the affair can be inherited resp. passed on. 

Affairs built with general properties are characterized as follows : 

1) they have a finite temporal duration, i.e. they extend over 
a well defined time in the lifespan of an object. 

2) they can be built with instances or prototypes, but not with 
classes. If the object is a prototype, the affair will be 
inherited by all instances of the prototype. If the affair 
happens to be invalidated, it will also be deleted for all 
instances which have inherited it before. 

Dispositions describe the predication of a property such that 

1) the affair exists without temporal limitation, 

2) the affair will be inherited by all specializations and 
instances of the involved objects, 

3) the first argument of the predicate must be a class or 
prototype (the remaining objects can be of arbitrary type). 

Events describe the predication of a property such that 

1) the property exists only at one moment in the lifetime of an 
object. As soon as a new event is created, this affair is 
automatically deleted. 

2) the corresponding affair can only be built with instances, 
and therefore cannot be inherited by other objects. 

5.2 Inference Mechanisms 

The system provides the following inference mechanisms: 

Retrieval (unification in PROLOG) 

Verification (resolution/backtracking in PROLOG) 

Creation and deletion of objects and values 
Subsumpt ion, i.e. genera 1 i zat i on/spec i a 1 i zat i on , 
class, instance, inheritance 

The characteristics of an object will generally be offered to all its 
specializations ("inheritance"). As characteristics we regard here all 
components and affairs of this object. The available characteristics of 
an object are : 

1) the characteristics, which the object has inherited from its 
generalizations, 
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2) the characteristics defined for the object, 
object A (generalization of B) 

i 

i 

j - offers inherited characteristics for further inheritance 
! - offers defined characteristics for inheritance or excludes 
| these (explicitly) from inheritance ("private characteristics") 

i 

i 

— (inheritance to) 

i 

i 

j 

i 

i 

— (inheritance from) 

i 

i 

v 

object B (specialization of A) 

- inherits characteristics from B 

- refuses inheritance from (offered) characteristics 
selectively and explicitly. 

When a component is defined, the inheritance to others can explicitly 
be excluded ("private component"). The definition of a characteristic 
blocks an inherited characteristic of the same name. An object can refuse 
the inheritance of a characteristic from other objects explicitly. 

For every affair the property name is entered into the AFFAIRS-slot of 
all involved objects. This property name will also be inherited by other 
objects, provided it is not explicitly excluded (by mentioning the 
keyword without__affair) . 

For the original affair also a PROLOG-fact is asserted. This fact has as 
predicate name the property name and as parameters the objects involved 
in the affair. 

6. Reconsidering the Example 

In general, we will not be able to deal with intensional phenomena as we 
do not have ways, so far, for accessing possible worlds. What remains are 
the following syntactic phenomena (taken to be extensional) that can be 
treated by the proposed extension of PROLOG: 

subordinate conjunctions (if-then, that, whether, &c), 
specifiers (al 1 , some, the (generic and not generic)), 
relative clauses, 
plurals, 
comparatives , 
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"can" with regard to numerical comparison, 
local adjuncts and prepositions, 
certain temporal adverbials (until, etc), 
instrumental prepositions (with, etc), 
certain WH-requests (who, what, whom, which, how many, 
when, where) . 

These requirements are fulfilled by the sample text, as need not be 
further demonstrated. 

In order that an update of this kind can automatically be added to the 
knowledge base, we briefly illustrate the kind of background knowledge 
that needs to be assumed. We begin by defining some objects using 
functions of the epistemic and conceptual level. 

: - defclass(vehicle) . 

def disposition (drives, [vehicle]). 

defclass(city) . 

createinstance(city, munich). 

createinstance(city, frankfurt). 

createinstance(city, nuremberg). 

defclass(cargo) . 

defclass(computer) . 

link_as__kind( computer, individual). 

defclass(personal_computer, [ [ i s a , cargo, computer]]). 

defclass(wine) . 

1 ink_as__kind(wine, mass). 



Notice, for example, that the class "vehicle" has been assigned the 
disposition "drives", i.e. a vehicle can by default be said to drive (in 
the sense of "can drive"). Moreover, whereas the class "computer" has 
been assigned the kind "individual", which is inherited, in particular, 
by its instance "peripherals", the class "wine" is assigned the kind 
"mass" . 

In the above sample text, the treatment of adjuncts, and hence the 
semantic interpretation of prepositions, represents a particular problem. 
While for some applications it may be acceptable to define predicates 
like 

drives_from_to(X, Y,Z) , 

this cannot be a general solution, as the number of possible adjuncts 
simply is too big and in most cases cannot be predicted, so that it is 
not evident which predicate to call for the retrieval of information. We 
therefore propose to treat of adjuncts by way of meta-predicates that are 
asserted of the respective PROLOG facts, such as accompaniment (for 
certain readings of "with"), reason, or time. (For a complete list, see 
HEYER/SCHNEIDER/KESE 1986a). 
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In order to also illustrate the update, we will present two sample cases 
of functions which the dialogue manager (DM) has to call in order to add 
linguistic information presented to it in form of DRSs to the knowledge 
base. 

To 2a): First an instance truckl of truck is created. (For the 

ACORD Prototype, the dialogue manager will only create 
instances of classes). Then it is checked if the citys munich 
and berlin are already known. If this is not so, for munich as 
well as berlin an instance from city has to be created. After 
this the corresponding affairs are created. 

createinstance(truck, truckl). 

> instances(city, Instances), 
member(munich, Instances) . 

> instances(city, Instances), 
member (berl in , Instances) . 

establishaffair(go[truckl]) . 

asserta(source(go[truckl] ,munich) . 

asserta(togoal (go[ truckl ] , berl in) . 

To 2b): It must be checked whether an instance peripherals of 

the class computer-accessories is already existent. If not, it 
must be created. 

> instances(computeraccessories, Instances) , 
member(peripherals, Instances). 
establishaffair(carries, [truckl, peripherals]). 

7. Summary and Conclusion 

The processing of natural language semantics for the purposes of 
knowledge base updates and queries poses deep and difficult problems. 
Some of these problems have been raised above. Given a general attitude 
of "everything can be made possible" within present-day AI research, we 
think it is important to point these problems out and rather attempt to 
structure them in a suitable way to allow for a modest treatment than to 
propagate a "we can solve it all" mechanism which is most likely to 
fail given the complexity of the issues. The extension of PROLOG that we 
propose to deal with some of the problems raised follows the KL-ONE 
approach of knowledge representation. We distinguish between three levels 
of representation: PROLOG, the epistemic level, and the conceptual level. 
The three levels are combined in an orthogonal manner such that, in 
particular, the functional and conceptual dimensions of knowledge can be 
easi ly combinded. 
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NEGATIVE ERKLÄRUNGEN IN EINEM EMYCIN-ARTIGEN EXPERTENSYSTEM-SHELL 
Britta Ladwig, Werner Mellis, Paderborn 

Zusammenfassung: Obwohl es naheliegend 1st 'WARUM NICHT'-Fragen an ein 
Expertensystem zu stellen, gibt es kaum Systeme, die eine negative Erklärung 
abgeben koennen. Es werden die theoretischen Grundlagen, Probleme der Imple- 
mentation und die Anwendungsmoeglichkeiten der für das Expertensystem-Shell 
TWAICE realisierten negativen Erklärungen beschrieben, 

1 Theoretische Grundlagen der negativen Erklärungen 

Der Erklärungsbegriff hat bekannlich mehrere Bedeutungsvari- 
anten (vgl. [7]): 

1. Erklärung von Tatsachen und Ereignissen 

2. Erklärung des Funktionierens eines Systems 

3. Erklärung als Handlungsanleitung 

4. Erklärung von Begriffen 

5. Erklärung als Festlegung durch die offizielle Funktion eines Sprechers 
Negative Erklärungen ('WARUM NICHT' -Erklärungen) sind eng verwandt mit 

Erklärungen von Tatsachen und Ereignissen, gehoeren aber genau genommen zu 
keiner dieser Varianten. Zwei verschiedene Arten von negativen Erklärungen 
koennen unterschieden werden. 

1. negative Erklärungen von Tatsachen oder Behauptungen, 

(d.h. Erklärungen des Nichtzutreffens von Sachverhalten und Behauptun- 
gen) 

2. negative Erklärungen von Handlungen, 

(d.h. Erklärungen des Unterlassens von Handlungen) 



Diese Arbeit entstand im Rahmen des vom BMFT gefoerderten LERNER-Projektes. 
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Diese beiden Arten lassen sich weiter unterteilen in Rechtferti- 
gungen und tutorielle Erklärungen. Das Ziel der tutoriellen Erklärung ist 
die zugrundeliegenden Zusammenhänge verständlich zu machen. Sie schließt 
die Rechtfertigung ein, die aber im allgemeinen nicht genügt, um die Adä- 
quatheitsbedingungen für tutorielle Erklärungen zu erfüllen. Auf tutorielle 
Erklärungen wird im weiteren nicht näher eingegangen. Die Information, die 
die negative Erklärung einer Handlung bietet, koennen in TWAICE, einem 
EMYCIN-artigen System, durch negative Erklärungen von Tatsachen und Behaup- 
tungen realisiert. Die Architektur von TWAICE ist in [6] beschrieben. 

1.1 Erklärungen (Rechtfertigungen) für das Nichtzutreffen eines 
Sachverhaltes 

Die Rechtfertigungen für das Nichtzutreffen von Sachverhalten, koennen 
ähnlich strukturiert werden wie die Rechtfertigungen von Tatsachen. D.h. sie 
zeigen, wie die zu erklärenden Sachverhalte mittels Vernunftgründen aus 
bekannten Sachverhalten abgeleitet werden. Bei der Erklärung von Tatsachen 
müssen alle beteiligten Sachverhalte zutreffen. Im Unterschied dazu dürfen 
bei der Erklärung von nicht zutreffenden Sachverhalten nicht alle als Prä- 
missen in der Ableitung benutzten Sachverhalte zutreffen. Man kann zwei 
unterschiedliche Antwortstrategien unterscheiden: 

Beispiel: 

Warum kommt nicht warme Luft aus dem Gebläse? 

(1) Die Heizung ist defekt, daher kommt kalte Luft aus dem Gebläse. Wenn 
Luft kalt ist, ist sie nicht warm. 

Aus Fakten werden auf der Basis von Vernuftgründen Fakten hergelei- 
tet, die dem zu erklärenden nicht zutreffenden Sachverhalt widerspre- 
chen. 
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(2) Die vom Gebläse angesaugte Luft 1st unterkühlt. Wenn die Heizung auf 
hoeherer Stufe betrieben würde oder der Luftdurchsatz geringer wäre, 
käme warme Luft aus dem Gebläse. 

Aus Fakten und nicht zutreffenden Sachverhalten wird auf der Basis von 
Vernunftgründen der zu erklärende Sachverhalt hergeleltet. Er ist 
dadurch erklärt, daß einige der in der Ableitung als Prämissen benoe- 
tigten Sachverhalte nicht zutreffen und daß ferner keine anderen Ver- 
nunftgründe existieren, die auf der Basis der zutreffenden Sachver- 
halte die zu erklärenden Sachverhalte abzuleiten gestatten. 

Rechtfertigungen des ersten Typs sind monoton, d.h. sie bleiben bei 
Erweiterungen des Wissens gültig. Bei Rechtfertigungen des zweiten 
Typs ist dies nicht allgemein der Fall. 

Erklärungen des ersten Typs sind nur sinnvoll, wenn ein System eine 
Wahl unter mehreren Handlungsalternativen hat, was bei EMYCIN- 
artigen Systemen nicht der Fall ist. Erklärungen des zweiten Typs 
geben eine Übersicht über die Gründe, warum alternative Ableitungsversuche 
gescheitert sind. Die alternativen Ableitungen werden wir im weiteren auch 
als hypothetische Ableitungen bezeichnen. 

1.2 Fraqeintention als Parameter bei der 'WARUM NICHT 1 -Erklärung 

Betrachtet man Erklärung unter dem Aspekt der Frageintention (vgl. 
[4], so kristallisieren sich 3 Benutzergruppen heraus: 

- Benutzer, die nach Fehlern im System suchen 

- Benutzer, die eine Rechtfertigung der Systemschritte verlangen 

- Benutzer, die aus den Ableitungen des Systems lernen wollen 

Die Frageintention kann demnach unterteilt werden in Verstehen und Prüfen. 
Erweitert man die Erklärungskomponente um negative Fragen, so muß die Fra- 
geintention als Parameter miteingehen. 
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Die 'WARUM NICHT' -Frage erweist sich beim Debuggen im System als 
außerordentlich nützlich. Das Prüfen ist eine typische Frageintention 
eines KE oder Experten. 

Wenn Erklärungen benutzerorientiert generiert werden, so wird bei die- 
ser Benutzergruppe zu Recht umfangreiches Gebietswissen vermutet, was ellip- 
tische Erklärungen bis an die Grenze des Unverständlichen zur Folge hat. Der 
Grund für die Auslassung von Informationen ist die Annahme, daß der Fra- 
gende sie kennt. Kann das System nicht von der Korrektheit des eigenen Wis- 
sens ausgehen, dann sollte es auch bei großer Kompetenz des Fragenden nicht 
unterstellen, daß er über das für die Ableitung relevante Wissen verfügt. 

Der Parameter "Frageintention" soll die Unterdrückung überf lüssiger 
Details der Erklärung bei der Intention "Prüfen" verhindern, und muß dem- 
nach explizit in das formale Modell einer 'WARUM NICHT'- Erklärung 
eingehen. 

1.3 Verschiedene Beweistiefe 

Bei der Aufstellung einer hypothetischen Ableitung müssen zwei 
Moeglichkeiten unterschieden werden: 

(1) Das 1-Stufen Konzept (lokale Begruendung) : 

Aufzeigen des letzten Argumentationschrittes: Welche Bedingungen 

koennten in einem Schritt zum erwarteten Ereignis führen ? 

(2) Das n-Stufen Konzept (globale Begruendung) : 

Aufzeigen aller Argumentationsschritte: Welche anderen Benutzerant- 

worten (nicht herleitbare Ereignisse) hätten zu dem erwarteten 

Ereignis führen koennen? 



Welches Konzept für die Beantwortung gewünscht wird, hängt von 
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der Fragei ntent Ion ab. Zunächst muß deshalb unterschieden werden, welche Vor- 
stellungen der Fragende über das System hat. 

Geht er von einem korrekten System aus, so hält er auch die hergelei- 
teten Resultate für korrekt. Wenn er ein anderes Resultat erwartet 
hatte, so moechte er seinen Denkfehler korrigieren. Hierzu benoetigt 
er eine lokale Begründung. Wenn der Benutzer die 'WARUM NICHT' -Frage 
jedoch als inverse Sensibilitätsanalyse interpretiert wissen 
moechte, er also wissen moechte, welchen Einfluß seine Antworten auf 
das Resultat hatten, so benoetigt er eine globale Begründung. Er 
erhofft eine Auskungt darüber, durch welche Antworten er zu dem 
erwarteten Ergebnis gelangt wäre. 

Geht der Benutzer jedoch davon aus, daß das System einen falschen 
Schluss gezogen hat, d.h. geht er von einem inkorrekten oder 
unvollständigen System aus, so benoetigt er die lokale Begründung. 
Er weiß, daß das hergeleitete Resultat falsch ist, und moechte 
nun wissen, woran die Herleitung des korrekten Resultates scheiterte. 

Durch iteriertes Fragen kann er schließlich bis zu einer globalen 
Begründung gelangen. Insofern also die lokale Begründung der elementare Bau- 
stein auch für die globale Begründung ist, besitzt sie den Vorteil groeßerer 
Allgemeinheit. 

2 Implementation von WARUM NICHT-Fraqen 

2.1 Architektur der erweiterten Erklärunqskomponente 

Die Inferenzkomponente von TWAICE verzichtet aus Durchsatzgründen dar- 
auf, auch über alle fehlgeschlagenen Ableitungsversuche Berichte zu hinterle- 
gen. 
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Eine Vorgehensweise wie sie in den Systemen EL oder BLÄH realisiert 
ist, kommt daher nicht in Frage. In diesen Systemen, die auf den strukturell 
ähnlichen Programmiersprachen ARS bzw. AMORD aufgebaut sind, werden während 
des Inferenzprozesses negative Berichte abgespeichert, die von der Erklä- 
rungskomponente nur noch verbalisiert werden, um das Scheitern eines Ablei- 
tungsversuchs zu dokumentieren. 

Für TWAICE wären zunächst zwei Ansätze für die 'WARUM NICHT' - 
Erklärungskomponente denkbar: 

(1) Erweiterung der Inferenzkomponente um Reports über das Scheitern von 

Regel anwendungen 

(2) Aufbau einer Komponente, die die relevanten Informationen über das 

Scheitern von Regel anwendungen rekonstruiert. 

Obwohl die zweite Alternative die anspruchsvol lere ist, wurde sie 
hier realisiert, da die Performanz der Inferenzkomponente hoechste Priorität 
besitzt. Die explizite Abspeicherung negativer Reports würde die Infe- 
renzkomponente sowohl zeitlich als auch speicherplatzmäßig belasten. 

2.2 Antwortstrateqie 

Bei der vorliegenden Implementation der 'WARUM NICHT' -Erklärung stand 
die Verwendung im Rahmen einer Debugging-Umgebung für den Knowledge 
Engineer oder den Experten im Vordergrund. Daher wurde die lokale Rechtfer- 
tigung mit Übersicht über alle Ableitungsalternativen als Antwortstrategie 
gewaehlt. 

Die Gründe seien hier noch einmal rekapituliert: 

Elementarität 

Durch die Realisierung des kleinstmoegl ichen, sinnvollen 
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Erklärungsschrittes sind den Erfordernissen des Debugging Rechnung 
getragen sowie der Anspruch des Benutzers auf einen sinnvollen Erklä- 
rungszusammenhang erfüllt. 

Modularität 

Durch iteriertes Fragen kann der Benutzer auch zu einer globalen 
Begründung gelangen. Ferner kann auf diese Weise die globale Begrün- 
dung nachträglich implementiert werden. 

Effizienz 

Im Gegensatz zur globalen Begründung, die ein vollständiges Abarbeiten 
moeglicher Herleitungsbäume erfordert und in Systemen mit großen 
Regelmengen (kommerzielle Anwendungen!) zu schlechtem Antwortzeitver- 
halten führt, läßt sich mit lokalen Begründungen eine individuell maß- 
geschneiderte, effiziente Erklärung erreichen. 

2.3 Ursachen des Scheiterns von Ableitunqsversuchen in 

TWAICE-baslerten Wissensbanken 

Denkbare Fehler in einer TWAICE-Wissensbank sind: 

(1) fehlende Regeln 

es existiert eine Situation, in der eine bestimmte Inferenz erwartet 
wurde, aber es gibt keine Regel, die in dieser Situation anwendbar 
ist. 

(2) fehlerhafte Konklusion in Regeln 

aus bereits bekannten Fakten werden Schlüsse gezogen, die nicht zum 
Kontext dieser Fakten gehoeren. 



( 3 ) 



zu allgemeine Regelprämissen 

aus bereits bekannten Fakten werden Schlüsse gezogen, die eigentlich 
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weitere Fakten benoetigen. 

(4) zu spezielle Regel Prämissen 

wenigere oder weniger spezielle Bedingungen hätten den Schluss ziehen 
koennen 

(5) konsultativ bedingtes Regelversagen 

- die Prämisse einer Regel schlug fehl, weil eine davon abweichende 
Antwort gegeben wurde 

- eine Antwort ist im Kontext zu den bisherigen Fakten nicht sinn- 
voll, was jedoch erst an späterer Stelle festgestellt wurde 
(Aufgabe eines Konsistenzcheckers) 

(6) falsch gesetzte Trigger 

eine Vorwärtsregel wurde nicht angewandt, weil ihre Triggerereignisse 
noch nicht eingetreten waren. 

2.4 Fragetypen 

Die realisierten ‘WARUM NICHT' -Fragen decken die verschiedenen Moeg- 
lichkeiten in TWAICE zur Formulierung einer Erwartungsfrage ab. Typen und 
Syntax lauten wie folgt: 

(1) warum nicht <obj>-<inst>. <attr> = <val> 

Warum wurde nicht der Wert <wert> hergeleitet, d.h. existieren 
Regeln, die diesen Wert herleiten und warum wurden sie nicht ange- 
wandt? 

(2) warum nicht <obj>-<inst> . <attr> = '?' 

Warum wurde kein anderer (beliebiger) Wert hergeleitet, d.h. existie- 
ren Regeln, die einen anderen Wert herleiten und warum wurden sie 
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nicht angewandt? 

(3) warum nicht <obj>-<inst> .<attr> KNOWN 

Warum wurden keine Werte hergeleitet, d.h. existieren keine Regeln, 
und wenn doch, warum konnten sie nicht angewendet werden? 

(4) warum nicht <obj>-<inst>.<attr> Regel NO 

Warum wurde zur Herleitung des Wertes nicht die Regel NO angewandt ? 
2.5 Ausqabebei spiel 

Es wird angenommen, daß unter anderen die folgenden Fakten in einer 

Konsultation hergeleitet wurden. 

Bauteil-1 . Eingangsspannung_l = 1 Volt 
Bauteil-1 . Eingangsspannung_2 = 0 Volt 
Bauteil-1 . Ausgansspannung = 7 Volt 

Als Wert für die Ausgangsspannung von Bauteil-1 erwartet der Knowlegde 
Engineer aber den Wert 4 Volt. Es folgt ein Konsolenprotokoll. Das System 
meldet sich mit '>', Eingaben stehen also hinter '>'. 

> warum nicht Bauteil-1. Ausgangsspannung = ? 

es existieren Regeln, die einen anderen Wert fuer Ausgangsspannung 
herleiten, doch sie haben 

UNERFÜLLTE PRAEMISSEN: 40 

NICHT EINGETRETENE VORWAERTSTRIGGER: 70 

Welche Regel moechten Sie sehen (Default = keine) ? 

> Regel 40 
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RULE 40 

IF Bauteil . Eingangsspannung_l = 0 Volt 

AND Bauteil . Eingangsspannung_2 = 1 Volt 

THEN Bauteil . Ausgansspannung = 4 Volt 

END 

Folgende Praemissen der Regel sind unerfuellt: 

Bauteil . Eingangsspannung_l = 0 
Bauteil . Eingangsspannung_2 = 1 

UNERFUELLTE PRAEMISSEN: 40 

NICHT EINGETRETENE VORWAERTSTRIGGER: 70 

Welche Regel moechten Sie sehen (Default = keine) ? 

> 

Hier ist die Erklärung über die Regel 40 abgeschlossen und es wird 
erneut angeboten unter den Regeln auszuwählen. 

Neben den im Beispiel angezeigten Gründen kann das System bei Bedarf 
weitere Gründe anzeigen. 

TRACE ABGESCHLOSSEN VOR REGELANWENDUNG: 

ZU NIEDRIGE KONFIDENZ: 

TABELLENPARAMETER SIND UNZULAESSIG: 

TERM- ODER PROZEDURPARAMETER UNZULAESSIG: 

2.6 Realisierungsprobleme 

Bei den Fragetypen (1) und (2) ist es wesentlich zu untersuchen, ob 
eine Regel den erfragten Wert ableitet bzw. ob sie einen anderen als den her- 
geleiteten Wert ableitet. 

Die Herleitung von Werten kann durch Wertzuweisung, Werttransfer, 
Tabellenaufruf, Zählfunktion, Termauswertung oder Prozeduraufruf erfolgen. 
Problematisch sind für den Rekonstruktionsansatz Herleitungen durch Wert- 
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transfer, Termauswertung und Prozeduraufruf . 

Unter Herleitung durch Werttransfer wird die Anwendung einer Regel der 

Form 



RULE 10 
IF <Bed1ngung> 

THEN objl . attrl = obj2 . attr2 
END 

verstanden. Zunächst müssen die für das Objekt obj2 der Konklusion zulässi- 
gen Objektinstanzen bestimmt werden, damit entschieden werden kann, ob durch 
Transfer des Wertes einer Instanz obj2-i von obj2 der gefragte Wert hätte 
hergeleitet werden koennen. Wenn das erfragte Objekt (Konklusionsobjekt) 
identisch ist mit dem zu transferierenden Objekt, so müssen sie durch die- 
selbe Instanz belegt werden, 

z.B.: Frage: warum nicht obj - 1 . attrl = 5 

Regel: IF ... THEN obj . attrl = obj . attr2 
==> obj - 1 . attrl = obj - 1 . attr2 

Wenn es sich jedoch um unterschiedliche Objekte handelt, so kann obj2 sich 
auf verschiedene Instanzen von obj2 beziehen. Auf welche Instanzen, wird 
durch den Instanzi ierungskontext der Regel anwendung bestimmt. Wurde die 
Regel für die Instanz objl-1 von objl angewendet, so enthält der Instanzi ie- 
rungskontext die im Sinne einer gewissen, vom KE definierten Zugehoerig- 
keitsrelation zu objl-1 gehoerenden Instanzen von obj2. Die Zugehoerigkeits- 
relation wird durch die relative Lage der Objekte objl und obj2 im stati- 
schen Objektbaum definiert. 

Ist das Konklusionsobjekt statischer Vorgänger des transferierenden 
Objekts, so enthält der Instanzi ierungskontext u.U. mehrere Elemente, 

z.B.: Frage: warum nicht obj2 - 1 . attr2 = 3 ? 

Regel: IF ... THEN obj2 . attr2 = objl . attrl 
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Dynamischer Objektbaum: 



obj2 - 1 

I 



obj2 - 2 



I 

obj4 - 1 



I 

obj4 - 2 



I I I I 

objl - 1 objl - 2 objl - 3 objl - 4 



Unter diesen Umständen kann die Regel mit objl instanziiert durch 
objl-1, objl-2, objl-3 und objl-4 angewendet werden. Es kann zum Zeitpunkt 
der Erklärung nicht entschieden werden, in welcher Instanz von Objekt objl 
der Wert des Attributs attrl transferiert worden ist, da sich der zum Zeit- 
punkt des Tracens von ob2-l . attr2 bestehende Kontext nicht mehr rekon- 
struieren läßt. Deshalb werden nur zwei Fälle unterschieden: 

der Wert von objl . attrl hat in keiner Instanz den gefragten Wert 

der Wert von objl . attrl hat in mindestens einer Instanz den gefrag- 
ten Wert 

Im ersten Fall ist die Anwendung der Regel zur Herleitung des Wertes 
nicht geeignet, im zweiten Fall muß untersucht werden, welche der Prämissen 
der Regel in welcher Instanzi ierung unzutreffend waren. 

Bei einer Termauswertung in der Konklusion kann nicht explizit ent- 
schieden werden, welche Werte unter welchen Voraussetzungen hergeleitet 
werden koennen. Dazu müßten alle zulässigen Werte der Argumentattribute in 
allen Kombinationen eingesetzt werden, was entschieden zu viel Zeit bean- 
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Sprüchen wurde. Wenn die zulässigen Werte für Argumentattribute, die in 
einer Termauswertung verwendet werden, lediglich auf v 'INTEGER' begrenzt 
sind, gibt es sogar unendlich viele Komb inationsmoeglichkei ten. 

Bei Regeln mit einer Termauswertung in der Konklusion wird grundsätz- 
lich davon ausgegangen, daß unter den herleitbaren Werten auch der 
gefragte sein koennte. 

Auch bei Regeln mit einem Prozeduraufruf in der Konklusion ist nicht 
explizit entscheidbar, welche Werte hergeleitet, bzw. nicht hergeleitet 
werden koennen. Auch hier müßten alle Wertekombi natonen der Eingangsattri- 
bute eingesetzt werden. Deshalb wird auch hier davon ausgegangen, daß die 
Regel geeignet ist, den gefragten Wert herzuleiten. 

2.7 Abschlußdiskussion 

Wie schon erwähnt, soll die implementierte 'WARUM NICHT' -Erklärung 
primär als Bestandteil der Debugging-Umgebung dienen. Der zugehoerige Ouput 
ist deshalb knapp und präzise und in einer sehr Informatik-nahen Sprache 
verfaßt (Begriffe wie Prämisse oder Trace wurden nicht übersetzt). 

Für die Zielgruppe der Endbenutzer Bedarf es daher noch einer eigenen 
benutzerfreundlichen Oberfläche. Prinzipiell beschafft die 'WARUM NICHT ' - 
Erklärung in TWAICE alle notwendigen Informationen, um sowohl den KE 
bei der Fehlersuche zu unterstützen, als auch dem Benutzer verständliche Ant- 
worten zu geben. Deshalb koennte durch die explizite Unterscheidung 
zwischen KE und Benutzer in der Konsultation eine hoehere Benutzerfreund- 
lichkeit leicht realisiert werden. 

Einem Benutzer kann dabei in zwei Punkten entgegengekommen werden: 



(1) verständlichere Ausgabeform 
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(2) falls gewünscht: rekursives Vorgehen des Systems zur Erlangung einer 

globalen Begründung 

Interessant ist, daß der Unterschied zwischen einer' WARUM NICHT' - 
Erklärung für den KE und einer für den Benutzer lediglich in der Wahl 
der Sprachebene liegen kann. Nach dem Modell von Wahlster (vgl. [8]), müßte 
dem KE eine verkürzte Erklärung gegeben werden, die bei ihm voraus- 
setzbares Vorwissen (z.B. Kenntnis der Regeln) nicht verbalisiert. Ist seine 
Frageintention jedoch die Prüfung der Wissensbank, muß die Ausgabe ausführ- 
lich erfolgen. 

3 Anwendunqsmoeqlichkeiten von 'WARUM NICHT' -Fragen 

3.1 Benutzeranwendunq 

Ein Benutzer erwartet von Erklärungen, daß sie Verständnis- 
schwierigkeiten beseitigen koennen. Die 'WARUM NICHT' -Erklärung übernimmt 
dabei die Aufgabe, zu erläutern, warum eine Schlußfolgerung gezogen wurde 
insofern als auf gezeigt wird, warum andere Wege scheiterten. Der Benutzer 
kann sich also bis hin zu seinen Antworten den anderen Weg anzeigen lassen. 

3.2 Debuggi nq-Anwendunq 

Die Untersuchungen, die der 'WARUM NICHT' -Erklärung zugrunde 
liegen, sind gleichzeitig die wesentlichen Untersuchungen in einem 
Debugging-Tool. Der KE erwartete ein bestimmtes Resultat, das nicht herge- 
leitet werden konnte und muß nun herausfinden, an welcher Stelle der 
Wissensbank der Fehler liegt. 

In der Debugging Komponente von TEIRESIAS (vgl. [3]) ist eine Unter- 
suchung von Regeln verankert, die der einer 'WARUM NICHT'-Frage entspricht. 
Der Unterschied besteht im Verwendungskontext und in der äußeren Form, da 
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nicht nach einem anderen Wert gefragt wird, sondern er wird konkret gefor- 
dert. 



Durch einen Dialog, der alle Konsequenzen darlegt, erfüllt das 
System den Wunsch des Fordernden. Mit Hilfe von 'WARUM NICHT'-Fragen kann 
der von TEIRESIAS geführte Dialog mühelos rekonstruiert werden (vgl. [5]). 

3.3 Anwendung als Diagnosemittel 

Üblicherweise werden in Systemen, die eine Diagnose stellen sollen, 
Symptomkombinationen auf Fehlfunktionen abgebildet. Der Benutzer wird nach 
den auf getretenen Symptomen gefragt, nach denen das System die Diagnose 
ableitet: 

z.B.: Wenn der Ventilator defekt ist, funktioniert der Foen nicht. 

Wenn das Kabel eingesteckt ist und der Schalter funktioniert und 

trotzdem kein Wind kommt, dann ist der Ventilator defekt. 

Solche Diagnosesysteme benoetigen eine große Wissensbank, da alle 
denkbaren Fehlerzustände beschrieben werden müssen. 

Stattdessen ist es nun moeglich eine Wissensbank zu erstellen, das das 
korrekte Funktionieren eines Systems beschreibt, um dann durch 'WARUM 
NICHT'-Fragen zu seinen fehlerhaften Teilsystemen zu gelangen. Hierzu ein 
Beispiel: 

Eine Wissensbank beschreibt mit wenigen Regeln das Funktionieren eines 
Foens. Die erste Regel sagt z.B. aus, daß ein Foen genau dann funk- 
tioniert, wenn seine Bestandteile (Heizung, Ventilator, Kabel, Schalter) 
funktionieren. Dies ist die wesentliche Regel, anhand derer durch die 

'WARUM NICHT' -Frage herausgefunden werden kann, welches Teil des Foens 

kaputt ist. Die übrigen 4 Regeln beschreiben das Funktionieren je eines der 
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Bestandteile. 

Es kommt zu folgendem Dialog: 

(1) Auf welcher Position steht der Schalter ? > 1 

(2) Ist das Kabel eingesteckt ? > ja 

(3) Kommt Wind ? > ja 

(4) Kommt heisser oder kalter Wind ? > heiss 
ERGEBNIS: Der Foen arbeitet nicht. 

> warum nicht foen-1. arbeitet = ja ? 

Es existieren Regeln, die * foen-1. arbeitet = ja 1 herleiten, doch 
sie haben 

UNERFUELLTE P RAEMISSEN: 10 

Folgende Praemissen der Regel sind unerfuellt: 

Schalter - 1 . arbeitet = ja 
Heizung - 1 . arbeitet = ja 

(D.h. Schalter oder Heizung sind defekt !) 

3.4 Konfigurationschecker als Konf iqurationsberater 

Mit TWAICE wurden ein Konfigurationschecker CONCHECK und eine Konfigu- 
rationsberater CONAD aufgebaut. Der Konf igurationschecker verfügt über 
Regeln, die die Constraints für eine zulässige Konfiguration beschreiben 
und überprüft damit eine vom Benutzer zu Beginn vorgegebene Konfiguration. 
Mit Hilfe der negativen Erklärungen kann mit der Wissensbank des Konfigurati- 
onscheckers das Verhalten des Konfigurationsberaters rekonstruiert werden. 
Das dabei entstehende Verhalten des Systems ist insbesondere dann interes- 
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sant, wenn ein Kundenberater bei normalen Anforderungen keine Schwierigkei- 
ten hat und daher nur Unterstützung in Spezialfällen sucht. Dann führt er 
zunächst seine Konfiguration ohne Unterstützung durch, gibt daher die 
Ergebnisse kontinuierlich in das System ein und startet den Konfigurations- 
check, wenn er nicht mehr weiter weiß oder glaubt fertig zu sein. Im Laufe 
des Checks werden dann automatisch die noch fehlenden Informationen abge- 
fragt. Lehnt der Checker die vorgegebene Konfiguration ab, so kann durch 
entsprechende Eingabe kann dann modifiziert werden. Wird danach die 
Konfiguration noch immer abgelehnt, kann das Vorgehen wiederholt werden, 
bis eine korrekte Konfiguration gefunden ist. Dieser Systemaufbau stellt 
einen systematischen Zugang zu kooperativen Expertensystemen dar, die das 
Vorwissen des Benutzers zu berücksichtigen gestatten und ihn nicht starr 
durch die vorgesehene Konsultation führen. 
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Abstract: The representation of dynamical systems according to the principles of 
qualitative analysis and simulation has two main aspects: the description of the 
topology for representing the structure of the system, and the description of the 
processes that run on the system. In this paper we introduce a process-oriented 
approach that allows to represent temporal and causal relationships, to discriminate 
continuous and discrete processes and to aggregate processes. The possible behaviors of 
a system can be determined by qualitative reasoning about processes, which is the basis 
for simulation. 



1 Introduction 



The knowledge of experts can be divided into experimental knowledge and knowledge 
about the domain specific relationships and mechanisms, the so called deep models. 
Deep modelling allows to derive knowledge using reasoning mechanisms. Experimential 
knowledge and compiled knowledge , i.e. knowledge inferred from deep knowledge about 
details, are often called shallow knowlege or surface knowledge , because the 
knowledge is not derivable from deep relations or because the underlying relations are 
neglegible on purpose. 

In expert systems we need the representation of shallow knowledge as well as deep 
knowledge. Shallow knowledge is convenient for fast solutions of typical standard 
problems, whereas deep knowledge is required for solving unusual, novel problems. 
Furthermore, it makes compiled knowledge explainable. Modelling and handling deep 
knowledge therefore is indispensable for knowledge based systems. 

The predicate 'deep 1 for modelling knowledge is not fixed, because a model can be 
refined nearly at pleasure. It is relative to the use of the knowledge base, i.e. to the 
tasks that are to be solved by it. 

When simulating the behavior of dynamical systems, deep modelling has two main 
aspects: 

- a topological aspect: structural description of a dynamical system by defining the 
components, their arrangement, and parameters; 
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- a dynamical aspect: description of changes running on the topology by means of 
processes. 

We do not want to give the details of the topologic description in this paper. The 
description can be done for example in COMODEL (COMponent Oriented DEscription 
Language, [5,9]), which is developed at our institution. 

CAPAS (CAlculus for Process Analysis and Simulation) can be used for deep modelling 
of real processes using a formal, qualitative process descripiton. This is treated in 
chapter 2. Chapter 3 gives a method for predicting all possible behaviors of the model 
of the system by means of qualitative reasoning. It is the basis for the simualtion of 
behavior starting from an initial situation. 

The deep modelling of processes can be characterised by the following points: 

- Representation of causal relationships. 

Example: 

The process 'closing a valve' causes a less area for flow. This effects that the 
pressure in front of the valve increases, which in turn causes the velocity of 
flow to increase. 

- Reduction of the domain of continuously varying parameters to discrete domains, 
in which qualitatively essential values or intervals of the domain are represented 
symbolically. 

Example: 

Reduction of temperature of water to the values 

less than 0 °C, 0 °C, greater than 0 °C and less than 100 °C, 100 °C, greater 
than 100 °C. 

- Representation of temporal relationships: 

Each process is assigned an interval in which the process is active. Temporal 
relations can be defined between the intervals to specify if a process runs in 
sequence to another, in parallel, overlapping, or anything else. 

- Distinction between continuous and discrete processes: 

Continuous processes are used to model continuous changes of parameter values, 
e.g. increasing of pressure in a container. Discrete processes are used to model an 
abrupt change, e.g. the flip of a circuits switch. Discrete processes correspond to 
the actions in planning systems (see for example [12]). 

- Description of processes in different levels of abstraction: 

Aggregation of processes to tiigher level' processes according to inherent and/or 
temporal criterions. 
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The approach described in this paper is an extension of the QP-Theorie of Forbus [6]. 
There are the following distinctions: 

- In addition to the continuous processes also discrete processes can be handled. 

- Temporal relationships between processes can be described and handled. 

- It is based on a deep modelling of the topology on which the processes run. 

- Processes can be aggregated from subprocesses. It is possible to specify temporal 
relations between them. Using this mechanism, the 'encapsulated histories 1 of 
Forbus can be described as processes. 

Further essential work on qualitative modelling and reasoning can be found in [3]. With 
regard to qualitative simulation the work of de Kleer [4] and Kuipers [10] are also 
relevant. De Kleers IQ-Analysis is useful for describing the topology, but it is not 
possible to describe the processes running on the system as separate units. Kuipers 
restricts himself to a direct qualitative interpretation of differential equations which 
are used in conventional simulation systems. 

2 Processes as Entities for Modelling Dynamical Change 

Intuitively a process is something related to change, motion, etc. We want to be more 
precise: 

A process is a change of a system over time. There are three kinds of changes that may 
occur in a system: 

- Adding and removing objects, 

- changes in position of objects, and 

- changes of values of parameters. 

The changes affected by a process are called influences of the process. A process 
always has a status; it is either active or inactive. Influences of a process operate if 
and only if the status of the process is active. 

2.1 Parameters 

The description of parameters is an essential part of the topologic description. 
Parameters are to hold characteristic properties of an object. A parameter X is 
defined by binding a set of values to it, i.e. each value of the set is a possible value of 
X. This set is called domain of X, the binding of the domain is called interpretation of 
X. Giving X a concrete value (i.e. an element of the domain) is called assignment to X. 
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Example: 

An object 'brick 1 is represented by the parameters length, breadth, height, and color. 
The first three parameters will be interpreted in the domain 'distance in cm', the 
parameter color in the domain: 

[ red, yellow, green, blue, pink with little green freckles ] 

A concrete cube may be described by the following assignment to the parameters: 

parameter: length breadth height color 

assignment: 10 10 10 green 

It is useful to distinguish two different kinds of domains: 

1. quantitative domains , which are inifinite sets of numerical values. These sets are 
totally ordered and dense in most cases, e.g. real numbers or 'distance in cm'. 

2. qualitative domains constisting of symbolic values. In general, these sets are 
finite and not ordered. A partial or total order is possible and sometimes may be 
induced by mapping a quantitative domain into a qualitative one. 

The topics qualitative values and qualitative interpreted parameters are used in an 
analogous way. 

Example: Parameters of the cube: 

The length is interpreted in the qualitative domain 'distance in cm'. The same 
parameter could also be interpreted in the domain 

Qlength = [ very short , short, medium, long ] 

on which no order is defined (even if the names of the elements seem to express 
one). To come to a total order of the qualitative domain we can define a surjective 
mapping 

O : 'distance in cm' -► Qlength 

which maps a partition of 'distance in cm' to the values of Qlength. 

In general parameters of objects are not constant rather they vary over time. The 
derivation of a parameter X w.r.t. time t describes this change of the parameter, i.e. a 
parameter is completely described by two values: 

- the amount, called A-value and 

- the derivation, called D-value. 

We write: A(<parametername>), D(<parametername>) 

If no ambiguity arises, we simply write <parametername> for A(<parametername>). 
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In the following the D-values of parameters will always be interpreted in the ordered, 
qualitative domain [ -, 0, + ]. That means: Let X be a parameter; 

D(X) = - iff X is decreasing, 

D(X) = 0 iff X is steady, 

D(X) = + iff X is increasing. 

As we already have seen, continuous and discrete processes are distinguished [11]. The 
ordering of domains being irrelevant for discrete processes becomes substantial when 
dealing with continuous processes. Parameters that are influenced continuously need to 
be interpreted in a domain with an (at least partial) ordering, because this is the basis 
for the changes that may occur. 

2.2 Temporal Relationships 

The QP-Theory of Forbus allows the modelling of temporal relations between two 
processes only in a rather rudimentary way. It is possible, for example, to express the 
simultaneous activity of processes but the formalism does not allow statements like: 
Process Pi occurs temporally before process P2* The simultaneous activity can only be 
specified implicitely in the slot 'QuantityConditions'. This implies the mixing of causal 
and temporal relationships which leads to difficulties in constructing a 'causality-chain* 
later on. 

For that reason we decided to allow the explicit specification of temporal 
relationships as far as they are known at time of modelling. The time representation 
approach used in CAPAS rests upon the interval based logic introduced by Allen [1], [2]. 
It has been adapted to the temporal behavior of processes in the following way: 

A time interval Ip is assigned to each process P. Ip represents the time from the 
start to the end of P. When no ambiguities arise, we simply write P for Ip. Let P- be 
the start and P+ be the end of Ip. Then the seven relations in Fig.2.1 may hold 
between two intervals J and K. 

In addition there are the six inverse relations: 

after (>), met-by (mi), overlapped-by (oi), contains (di), started-by (si) and 
finished-by (fi). 

In total there are 13 different relations that may hold for ordered pairs of intervals. 
We call them AR (Alien-relations): 

AR = { m, mi, <, >, =, s, si, d, di, f, fi, o, oi } 
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Relation 


Symbol 


Picture 


Semantics 
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Fig. 2.1: Temporal Relations between Intervals 

In many cases the temporal relation between two intervals is not exactly known. So we 
allow the relation to be specified as a disjunction of Alien-relations: 

Notation: J {ri, r2, ...» r n } K 

For the 13 AUen-relations being exclusive» only one of the relations can hold. 
Therefore the set above will be interpreted as: 

Taxonomy ((J ri K), (J r2 K), ...» (J r n K)) = tt, 
i.e. for exactly one relation ri ( J ri K) = tt. 

Examples: 

J {f} K J finishes K 

J {fi} K J f inished-by K = K finishes J 

J {o,d,si} K J overlaps K or J during K or J started-by K 

2.3 A Formalism for Describing Processes 

In this section we will define a syntax for describing processes. We will introduce the 
semantics informally by explaining the meaning of the different slots. The semantics is 
defined implicitely in chapter 3 by mapping into a state-transition-like diagram called 
behavior graph. Up to now the formalism only allows to describe changes in parameter 
values. The formalism is general enough to be extended for describing the other kinds 
of changes as well. 
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2.3« 1 A Syntax for Processes ( in BNF ) 



<process> 

process 

objects 

[params 

[subprocesses 



conditions 

[relations 

influences 

<processname> 

<parameter> 

<domain> 

< constant» 
<AR> 

<allenrelation> 

<cond> 

< relation» 
<prop» 
<cont-infl> 
<disk-infl» 



<processname> ; 

COMODEL-expression ; © 

<parameter» s <domain» { , <parameter» s <domain»} ; ] 
[<processname» { , <processname>}] ; 

[<processname> <AR> <processname> 

{ , <processname> <AR» <processname>}] ; ] 

[<cond» { , <cond» }] $ 

<relation» { , <relation»} ; ] 

[<cont-infl» { , <cont-infl»}] ; | [«disk-infl» { , «disk-infl»}] ; 
::= < identifier»® 

::= «identifier»® 

::= *[* «constant» { , «constant»} *]*® 

::= «identifier»® 

::= *{* «allenr elation» { , «allenrelation»} *}*® 

::= m | mi | > | « | = | d | di | s | si | f | fi | o I oi 
::= «expression»® 

::= «parameter» «prop» «parameter» | «expression»® 

::= -±—> | ----- > 

::= D(«parameter») = + | D(«parameter» = - 
::= «parameter» = «constant» 



Remarks: 

© ’COMODEL-expression* is a description of a topology . It is written in a description 
language for topology, e.g. CO MODEL. 

® «identifier» is defined in the usual way (e.g, like in PASCAL [8]). 

® The characters in quotes *{*, *}', *[*, and *]* respond to the notation of processes, i.e. 
they are no meta-constructors of the BNF. 

® «expression» is defined in analogy to PASCAL-syntax. The type of «expression» must 
be BOOLEAN (like the conditions in IF- and WHILE-statements in PASCAL). 




2.8.2 The Me aning of the «lota 



process i 


The name of the process is specified. For further explanations this 
process is called P. 


objects : 


This slot describes the topology on which process P can run. This may 
be the topology of the whole system or some part of it. 


parcuns : 


Definition of names and domains of all local parameters. Parameters 
are called local, iff they 

1. appear in at least one of the slots Conditions', 'relations', or 
'influences' of process P and 

2. either are not defined in processes that exist in the process 
hierarchy above P, or are defined there with other domains. 


subprocesses : 


Definition of the names and temporal relations of subprocesses. The 
declaration of the temporal relations is optional. They constrain the 
number of possible behaviors of the system and make the analysis of 
behavior (chapter 3) more efficient. 


conditions : 


Activity conditions for process P. 

There are two necessary conditions to be satisfied for a process being 
in status active during time-interval J: 

1. The conjunction of all activity conditions is 'true'. 

2. The status active is possible w.r.t. the temporal relations declared 
in the subprocesses-slot of the father process. 

Conditions 1. and 2. together are also sufficient for the status of 
process P being 'active'. 


relations : 


Proportionalities and relations that hold during the activity of the 
process. 

Proportionalities allow to express that a parameter X is proportional 
to a parameter Y (X Y) or inversely proportional (X — : — > Y). 

A change of X will automatically change Y as well. This is called an 
indirect influence of the process on Y. 


influences : 


Direct influences of process P on paramters. 

A continuous process may influence a parameter X by saying that it is 
continuously incrementing (D(X)= +) or decrementing (D(X)= -). 

A discrete process assigns a discrete value to some parameter X 
during or at the end of the interval of process activity (X=<constant>). 




177 



2.4 Example: Preparing Espresso 



O 




heat-source switch 



Fig. 2.2: Espresso-machine 

This apparatus for preparing espresso may be topologically structured like in Fig. 2.3. 

To explain the ’physical background* of the system we will start from the following 
state: 

1. The cooker ist turned off. 

2. The espresso- machine ist filled, i.e.: 

- There is water in the water pot, 

- the coffee pot is empty and 

- The powder container is full of coffee powder. 

3. The espresso-machine is on the cooker. 

We simplify the process of preparing espresso with this apparatus to the following: 
When switching-on, the heat-source will become hot. A heat-flow from heat-source to 
water-pot is started. Heating up the water will effect the generation of some steam. 
This increases the pressure in the water-pot, what in turn will cause the hot water to 
be pressed through the standpipe and coffee powder into the coffee-pot. The process 
ends when neither the water-pot nor the standpipe contain any liquid. 
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component (lowlevel units of topologic description) 



aggregates (highlevel descriptions combined of components 
or aggregates) 



N 

subtops 

params 



name of the unit 
subaggregates or components 
parameter 



Fig. 2.3: Topological Structure of the System 



With regard to the limited extent of this paper we will confine us to the following four 
processes: 

1. switching-on and switching-off: 

We assume an ideal heat-source, i.e. after switching on the heat-source is 
immediately hot, in the moment of switching off it is immediately cold. 

2. boiling-water: 

This process models the generation of steam and pressure in the water-pot. 

3. transporting-liquid: 

Transport of liquid from water-pot to coffee-pot. 

We do not care about the process of heating the surroundings of the system, the 
chemical process of transmuting the water into espresso, and some other processes one 
can imagine. 
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process preparing-espresso; 

objects espresso-machine-on-cooker; 

params switch.position : [on, off], 

heat-source. temp : [cold, hot], 

total-amount-of-liquid : [0, partial-amount, total-amount, max- 

amount], 

water-pot. amount : [0, partial-amount, total-amount, max-amount], 
coffee-pot.amount : [0, partial-amount, total-amount, max-amount], 
water-pot.steam s [0, greater-thanO], 
water-pot. pressure :[low, rising-pressure, high]; 

subprocesses switching-on, switching-off, boiling-water, transporting-liquid; 

switching-on {m} boiling-water, 
switching-on {<} transporting-liquid, 
transporting-liquid {m,<} switching-off, 
boiling-water {m,<} switching-off; 

conditions total-amount-of-liquid > 0; 

relations water-pot. amount + coffee-pot.amount = total-amount-of-liquid, 

water-pot. amount coffee-pot.amount; 

influences D(water-pot.amount) = -; 

process switching-on; 

objects cooker; 

conditions switch.position = off; 

influences switch.position =on; 

heat-source.temp = hot; 

process switching-off; 

objects cooker; 

conditions switch.position = on; 

influences s wit exposition =off; 

heat-source.temp = cold; 

process boiling-water; 



objects 

conditions 



heat-source, water-pot; 
heat-source.temp = hot, 
water-pot. amount > 0; 
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relations water-pot.ste&m —£—> water-pot. pressure; 

influences D(water-pot.steam) = +; 

process transporting-liquid; 

objects Espresso-machine; 

conditions water-pot.pressure 2 rising-pressure, 

water-pot.amount > 0; 

relations water-pot.amount — ^-> water-pot.pressure, 

water-pot.amount — ri -> coffee-pot.amount; 
influences D(water-pot.amount) = -; 

The specified temporal relations between the subprocesses are demonstrated in Fig. 
2.4. 

Process Interval 



switching-on 
boiling- water 
transporting-liquid 
switching-off 



h 



H 



Fig. 2.4s Temporal Behavior of the Subprocesses 



3. Analysis of Behavior 

3.1 Temporal and Inherent Dependencies between Processes 

Section 2.3 presented a formalism for process modelling, which allows to describe the 
behavior of a dynamical system in distinct levels of abstraction by a hierarchy of 
processes. Let P be an aggregated process of level i and Pi,...,P n its subprocesses (Fig. 
3.1). The subprocesses Pi,...,Pn describe the detailed behavior of P at level i+1. Each 
subprocess describes a partial aspect of the behavior of P. The goals are to analyse the 
dependencies between the subprocesses of P and to generate a behavior graph 9 which 
describes all possible behaviors at level of abstraction i+1. Nodes of the behavior graph 
are process configurations (in short: configurations). A process configuration is a set of 
processes, which are active in the same time-interval (subsets of {Pl,...,PnJ)« The 
directed arcs are interpreted as possible transitions between process configurations . 
They describe the activation and deactivation of processes. There is a set S of 
startnodes and a set E of endnodes. For finite processes S = E = Q. Each path from a 
start- to an endnode describes one possible behavior of P. The behavior graph therefore 
is the basis of simulation . 
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Fig. 3.1: Hierarchy of Processes 

There are two kinds of dependencies between subprocesses: 

1. Temporal dependencies: 

The previously known temporal relations between the subprocesses Pi>...,Pn are 
constituted in P. By temporal reasoning it is possible to infer sets of processes, 
that can simultaneously be active and the possible sequences of process 
configurations, i.e. the configurations and transitions between them that are 
possible under the temporal restrictions. 

Example: 

Let Pi and P2 be the only subprocesses of P, and (Pi {o} P 2 ) a given temporal 
relation. The behavior of P can be described by 

(Pi) - {Pl,P2) - {P2) 

i.e. at first Pi is active, then both subprocesses are active, then P 2 . 

2. Inherent dependencies: 

Processes interact by shared influences along common parameters. Different 
active processes can affect the same parameter directly or indirectly or a process 
can affect a parameter mentioned in the activity condition of another process: 
the condition of an inactive process can become valid or the condition of an 
active process can become invalid (change of status). The analysis of this kind of 
interaction is called limit analysis [6]. It is performed in two steps; each kind of 
interaction is handeled in one step. The order of the steps is essential, because 
the results of step I ) enter step 1 1 ). 

I )For process configuration PC determine the induced changes of parameters as 
follows: 

Direct influences of one process: 

All expressions that are listed under slot influences; 
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Indirect influences of one process: 

Ql -±~> q 2 : D(Qi) = q -♦ D(Q2) = q 
Ql > Q2 * D(Qi) = q D(Q 2 ) = q 



r + if q= - 

where q € {-,0,+}, <f= 0 if q= 0 

if q= + 



Multiple influences on the same parameter X are combined as follows: 

Let Di(X) and D 2 (X) be single influences or intermediate results. The table 
specifies their concatenation Di(X) o D 2 (X): 




The table shows the nondeterminism caused by contrary influences. 
Sometimes a conflict may be resolved by the previously known temporal 
relations. It may also be possible (but is not done in this approach) to make a 
refined subdivision of the domain of the D-values. Nevertheless, a conflict 
resolution is not always possible. 

Example: 

Assume the process definition of section 2.4. 

Let PCi = (boiling-water, transporting-liquid} be a process configuration. 
The following changes of parameters are caused in PCi: 
D(water-pot.amount) = D(coffee-pot.amount) = +, 

D( water-pot. st earn) = +, 

D(water-pot.pressure) € {-,0,+}, because heat-up-water has positive, 
transporting-liquid negative influence on pressure. 

Let PC2 = {switching-on} be a process configuration consisting of a 
discrete process. 

Changes of parameters: 

A(switch. posit ion) = on, A(heatsource.temp) = hot. 

ll)For a process configuration PC determine, which processes can change their 
status due to the changes of parameters determined in I ). If more than one 
process can change its status, it is not realistic to assume that they all do it in 
the same moment. Instead all temporal sequences in change of status are to be 
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considered. By this you get all successor configurations PCi,...,PCn» which are 
possible under inherent dependencies. 

Example: 

Let (Pi,P2) be a process configuration. Assume that the result of the 
limit analysis is that P2 becomes inactive and P3 active. The following 
transitions are possible: 



{P1,P2} 




{Pi} {Pl,P2>P3) (Pl,P3) 

Here an essential advantage of the use of previously known temporal 
relations can be seen: it is possible that some transitions can bee excluded 
because they are not valid under temporal restrictions. 

The analysis of behavior makes two fundamental assumptions: 

- all changes are caused directly or indirectly by processes; 

- beyond the influences induced by the processes defining a system, there are no 
further influences ('closed world assumption*). 

These assumptions imply, that the D-value of all noninfluenced paramters is 0. 

The analysis of the temporal and inherent dependencies are essential parts in 
generating the behavior graph. For a process configuration PC, the allowed successor 
configurations SPC are determined as follows: 

1. TPC = successor configurations, that are possible under temporal dependencies 

2. IPC = successor configurations, that are possible under inherent dependencies 

3. SPC= TPC n IPC. 

This is illustrated in the next section by means of the espresso-example. 



3.2 Example: Preparing Espresso 

For the process preparing-espresso and its subprocesses, which we have specified in 
section 2.4, we get the following behavior graph: 
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0 

I 

{switching-on} 

1 

* {boiling- water} 

no possible transition; 

. gets eliminated by limit analysis. 



{boiling- water, {transporting- liquid} 

transporting-liquid) 




0 



x t 

{switching-off} 0 

Fig 3.2: Behavior Graph for Process Preparing-Espresso. 

As an example, the transition from * to ** and vice versa is discussed in detail: 

♦ -♦ ** : 

PC = {boiling-water} 

A-values known : switch.position = on, heat-source. temp = hot, water-pot. amount > 0 

Changes in parameters: D(water-pot.steam) = +, D(water-pot.pressure) = + 

TPC= {{boiling-water, transporting-liquid}, {transporting-liquid}} 

IPC = {{boiling-water, transporting-liquid}, {switching-off}, 

{switching-off, boiling-water, transporting-liquid}} 

SPC = {{boiling-water, transporting-liquid}}. 

*♦-*>*: 

PC = {boiling-water, transporting-liquid} 

A-values known: switch.position = on, heat-source.temp = hot, water-pot. amount > 0 
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Canges in parameters: 

D(water-pot.amount) = D(cof fee-pot. amount) = +, 

D(water-pot. steam) = +, D(water-pot.pressure) € {+,0,-} 

Possible changes in status: 

switching-off can become active, 

transporting-liquid can become inactive, because pressure is decreasing, 
transporting-liquid and boiling-water can become inactive simultaneously, because 
water-pot. amount becomes 0. 

TPC= {{boiling-water}, {transporting-liquid}, 0, {switching-off}} 

IPC = {{boiling-water}, 0, {switching-off}, {switching-off, boiling-water}, 
{switching-off, boiling-water, transporting-liquid}} 

SPC = {{boiling- water}, 0, {switching-off}} 

4. Conclusion 

In this paper a new calculus for qualitative analysis and simulation of dynamical 
systems has been introduced. It allows to represent the structure and behavior of 
processes, including the topology, on which the processes run. Up to now it is only 
possible to describe changes in values of parameters. It is not possible to reason about 
changes in existence of objects or in general changes of the topology. It is easy to 
modify the calculus such that parameter conditioned changes of existence can be 
handeled, e.g. water disappearing [7] . Furthermore it is not possible to describe 
previously known cyclic behavior, e.g. oscillation, in terms of the Alien-relations. The 
temporal calculus must be extended such that cyclic behavior can explicitly be 
described. 

In CAPAS the process representation formalism is applied to simulation of dynamical 
systems, e.g. physical, biological, chemical, or perhaps economical systems. Simulation 
is not only used for pointing out the possible behavior of systems, but also for detecting 
errors and inconsistencies made by the engineer while developping system models. 
Another application area is the computer aided instruction. The process models can be 
used for generating explanations a student will find easy to understand. Applications to 
process control may also be possible. 
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Zusammenfassung. Die hier beschriebene Arbeit ist ein Teil des FORK Projekts, das 
die Implementation eines primär objekt-orientierten Wissensrepräsentationssystems und 
seine Anwendung auf den Entwurf und die Fehlerdiagnose technischer Systeme zum Ziel 
hat. Innerhalb dieses Rahmens wurde eine erste Untersuchung im Bereich des Diagnose 
durchgeführt, um Klarheit über die grundsätzlichen Probleme und die Anforderungen 
an sprachlichen Ausdrucksmitteln für Repräsentationsschemata zu gewinnen. Nachdem 
zuerst eher traditionelle regel-basierte Ansätze für das Diagnoseproblem betrachtet wor- 
den waren, wurde dann die Zweckmäßigkeit von Diagnoseansätzen untersucht, die mit 
Hilfe von expliziten Beschreibungen des zu diagnostizierenden Systems (auf der Grund- 
lage seiner Struktur und Arbeitsweise) Vorgehen. Aufbauend auf einen Algorithmus zur 
Fehler diagnose in elektronischen Schaltkreisen, erwiesen sich beträchtliche Erweiterun- 
gen für den Fall elektromechanischer Systeme — zur Einbeziehung zeitlicher Abläufe und 
geometrischer Information — als notwendig. Da die objekt-orient ierte Implementation 
des resultierenden Diagnosesystems DIAGTECH den Einschränkungen eines Personal 
Computers genügen mußte, stand nur eine Teilmenge der Ausdrucksmittel größerer Sy- 
steme wie des FORK-Systems zur Verfügung. DIAGTECH ist allerdings ein hybrides 
System, da es auch den regel-basierten Diagnoseansatz unterstützt; für letztere Aufgabe 
wurde unser logik-basiertes “Expertensystem- Werkzeug” DUCKITO herangezogen. 
Abstract. The work described herein is part of the FORK project, which aims at the 
implementation of a primarily object-oriented knowledge representation system and its 
application to the design and fault diagnosis of technical systems. Within this frame- 
work, a first study in the field of diagnosis has been conducted, aiming at a clarification 
of the basic problems and representational needs. After having considered more tradi- 
tional rule-based approaches to the diagnosis problem, we investigated the suitability 
of approaches which operate on explicit descriptions of technical systems (“based on 
structure and behavior”). Starting with an algorithm to diagnose multiple failures in 
electronic circuits, considerable extensions had to be made for the more complicated case 
of electromechanical systems with regard to temporal and spatial (geometric) relations. 
Since the object-oriented implementation of this diagnosis system, DIAGTECH, had to 
obey the restrictions of a Personal Computer, only a subset of the representational fea- 
tures offered by larger systems like the FORK system was available. But DIAGTECH 
is a hybrid system, because it also supports the rule-based style of diagnosis, for which 
our logic-based “expert system shell” DUCKITO is used as a subsystem. 
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1 Introduction 

The work reported here is part of the FORK project, which aims at the implementation 
of a primarily object-oriented knowledge representation system 1 to provide descriptive 
means which are well suited for the design and fault diagnosis of technical systems. 
Therefore, a first study in this field has been carried out to identify the basic problems 
and representational needs. 

Improvement of the fault diagnosis of technical systems is of a large economic im- 
portance. But often this task is very complex in nature and requires a lot of practical 
experience as well as knowledge of the underlying technology and of the structure and 
behavior of the failing device. 

To quote Davis and Shrobe [6], when a piece of machinery begins to malfunction, it 
can be diagnosed and repaired in two characteristically different ways: 

1. An experienced operator might recognize the symptoms and take corrective action 
using his previous experience in dealing with the problem. 

2. An experienced engineer may be able to reason his way through the problem using 
an understanding of electronics and electromechanics. 

The first approach — as in early expert systems like MYCIN — relies on large 
collections of inference rules that associate symptoms with diagnoses and cures. 

In the second approach, reasoning “from first principles” plays a central role: trac- 
king down the problem by reasoning about the structure and behavior of the device in 
question. A central part of this ability is the skill of using functional and structural 
descriptions. 

While most investigations within this framework (cf. e.g. Davis [7], Genesereth [11], 
DeKleer and Williams [9]) concentrate on the diagnosis of electronic circuits, we applied 
it to electromechanical systems — with the concrete example of a press — to test its 
suitability. 

2 Diagnosis Based on Structure and Behavior of 
Technical Systems 

In a first approach to technical diagnosis, it is usually characterized in the following 
way: A set of symptoms characterizes (in general not one-to-one!) a specific fault, 
or, inversely, a fault denotes a characteristic set of symptoms. A fault is in general 
thought to be a separate entity which influences particular components of the device. 
The components which are impaired in their functionality become manifest indirectly 
in the form of observable symptoms. 

Because the final goal of diagnosis is to reestablish the system in a functioning state, 
the repair problem perspective provides the most general framework. The very first 
step in diagnosis is fault recognition , which in technical systems usually is part of the 
control or supervisor mechanism. Diagnosis in the sense we are interested in it starts 
with a recognized malfunction and tries to find one or more faults where in general it is 



l cf. [1,3,19] 
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assumed that the repair procedures are associated with faults or classes of faults. On 
the other hand, the space of possible diagnoses is limited by the possibilities to repair 
the equipment, e.g. by exchange of components. 

A fundamental property of the diagnosis of technical systems is that it is dealing 
with artifacts which have been designed and built by humans for a certain purpose. 
Usually design information is given by drawings, part lists or operational specifications 
which allow an experienced diagnostician to imagine how the various components of the 
system interact such that he can draw conclusions on possible causes for an observed 
malfunction. 

Envisionment , the ability to imagine dynamic processes, is one of the important parts 
of the diagnostic process. The structure-and-behavior based approach to diagnosis tries 
to model this ability. 

It starts with — possibly hierarchically ordered — representations of the characte- 
ristic structure (topology) of the system and of the behavior of its generic components. 
This information makes it possible to deduce the behavior of the system as a whole. 
The main step of diagnosis is therefore to record differences between the observed beha- 
vior of the real system and the behavior of the model gained by qualitative simulation 
and to infer from those structural discrepancies which explain the observed malfunction. 
Hence, any deviation of the factual structure from its model counts as a cause of error, 
i.e. it is only of interest whether a component is defective and not in which way it is 
defective (“no- fault-modes principle”). The general repair conditions imply that faults 
are identified with defective components. 

3 The Algorithm of DeKleer and Williams 

As a first step in the realization of our diagnosis system the kernel of DeKleer ’s and 
Williams’ algorithm [9] has been implemented in a modified version. 2 In the following, 
we give a brief overview of our implementation DIAGMUFA (DIAGnosis of Multiple 
FAilures) . 

The algorithm is based on a (object-oriented) description of the system as a con- 
straint network } in which values are propagated (qualitative simulation) and dependences 
are recorded. In our object-oriented implementation, 3 the components (nodes of the net- 
work) as well as the connectors (edges of the network) are represented by objects which 
are connected with each other by explicit pointers. In propagating values (realized 
by message passing ), the visited components are assumed to function correctly. This 
fact is recorded in an assumption set , which is assigned to each value. In contrast to 
the original constraint paradigm, values computed on different propagation paths for a 
connector are not only allowed, but the starting point for diagnosis. If two values of 
a connector do not agree, the union of their assumption sets results in a conflict set, 
which serves to identify possible candidates. 

There is a distinction between 

• Conflict: A set of components, of which at least one is malfunctioning; and 

2 In contrast to their approach, no ATMS [8] (see last section) was available to us, and fault probabilities 
as well as optimization techniques were not implemented. 

3 For object-oriented programming cf. [18,20,1,3] 
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• Candidate: A set of components, whose simultaneous malfunctioning explains all 
symptoms. 

These definitions imply that each superset of a conflict or candidate is also a conflict 
or candidate, respectively. Therefore, focussing on minimal candidates (and conflicts) 
is sufficient, because they already characterize all possible candidates (conflicts), which 
leads to a variety of heuristics to constrain combinatorial explosion of the propagation 
of multiple values. 

The generation of minimal candidates from new, emerging conflicts and already 
known candidates is performed incrementally using an agenda and some queues. The 
minimality heuristics are built in into the propagation mechanism. 

A candidate explains a conflict, iff both sets have at least one component in common. 
Whenever a new conflict is detected, the set of minimal candidates is modified in 
the following way: Each candidate which does not explain the new conflict is replaced 
by exactly as many new candidates as do result from supplementing him by one of the 
conflict’s components in turn. 

4 Means of Description 

For the purpose of modelling, the representation language for technical systems has to 
provide sufficient expressive power in order to fulfill the following requirements: 

• The description must include an object-oriented representation of components and 
connectors; 

• The components must have a well-defined input-output relationship , i.e., they can 
be considered as black boxes which react to any input with a well-defined output; 

• The flow of information between components — along the paths defined by the 
connectors — has to represented; 

• Hierarchical descriptions are advantageous to limit the complexity of the algo- 
rithm, which is NP-complete in spite of all minimality heuristics. 

5 A Diagnosis Algorithm for Electromechanical Sy- 
stems 

Our diagnosis system aims at the domain of electromechanical systems which offers 
additional problems compared with the domain of electronic circuits, from which the 
familiar examples in the literature are drawn. As a protoype application, we chose 
an electromechanical press, for which a physical model had been built of “Fischer- 
Technik” parts, including a programmable control unit manufactured by Siemens AG. 
The electromechanical device consists mainly of two parts, a pusher and a press, which 
are arranged in such a way that within an operational cycle defined by the control unit, 
an imaginary workpiece is pushed to a place below the press stamp, then pressed, and 
finally pushed out of the device (from left to right in Fig. 1). Each of the two subsystems 
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contains an electromotor and a mechanical power transformation mechanism with gears, 
gearwheels, a helix, etc. 

A set of switches (sensors) which are connected to the input port of the control unit, 
signalize the actual positions of the pusher and the press stamp. The control unit starts 
the electromotor through specific output ports. 

Modelling this plant for our diagnosis system, we distinguish several levels of descrip- 
tion. On the first level, we have to represent two disjunct functional units, pusher and 
press, which axe not directly connected with each other, but each in turn is connected 
with the control unit (viz. Fig. 2). The control unit itself is not represented in the 
model, because it shall not be regarded as a candidate, i.e., it is assumed to behave 
correctly. The course of the technical process may not be confused with the behavior 
of the system or its components. On this level, the behavior can only be expressed in 
terms of delayed signals from the sensors to the control unit. 

Although this first level of description is trivial with respect to diagnosis (inconsistent 
signals refer directly to the respective component), it shows the necessity to represent 
the aspect of time . The control unit and delays in the mechanical parts enforce the 
modelling of events in time. In our example, the following order of events is given: 

1. Starting position — ► Time TO 

2. Move pusher forward — » T1 

3. Press — ► T2 

4. Move pusher to final position — ► T3 

5. Move pusher back — > T4 

6. Goto 1. 

Therefore the algorithm has to be extended, because two values for a connector 
are conflicting only if they occur during overlapping time spans. To achieve this goal, 
the agenda mechanism for handling propagation is augmented with another dimension: 
Time serves as a second ordering criterion for an agenda, the elements of which are in 
turn agendas, not queues. The control signals as well as other delays are entered first 
into the agenda. As the next step, the message with the smallest assumption set at the 
earliest (present) point of time is sent. 

Furthermore, the connectors have to be modified, because in addition to propagate 
and record multiple values, they also have to record the respective time spans. For 
this purpose we adopted from JACK [10] the concept of discrete time intervals , which 
constitute “ histories ”, and assigned a history to each connector. A history is a stack 
of “episodes”, each of which consists of an interval and a list of “nodes” which are 
valid within it. The intervals of a history (and, accordingly, their episodes) are pairwise 
disjunct , i.e. whenever a node whose interval overlaps one or more episodes has to be 
entered into a history, these episodes are split into a sufficient number of new episodes 
and their nodes are copied accordingly. 

On the second level of description, where we consider the pusher and the press per 
se, we recognize as their main parts the motors as sources of power and the power 
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transformation mechanism consisting of gears, gearwheels, etc. But in order to fulfill 
the requirement of a unique input /output behavior, these parts can not be mapped one- 
to-one on components in our sense. Instead, each functional unit is modelled in terms 
of System Dynamics [16]: As power transmission chains consisting of “two-energy- 
p ort ” -components . The parts are represented by redundant pairs to which a unique 
behavior can be assigned. A few simple component are sufficient for our model: source, 
rotinverter, rotransmitter, rot—*trans (= rotation-to-translation transformer). Power 
transmission is simulated by propagation of symbolic values ( posrot , negrot, stand ) . 

Positions of e.g. the pusher are recorded as states, because we don’t have an explicit 
representation of the geometry of the device. Furthermore, on this level of representa- 
tion, the whole rotation-to-translation transformation mechanism has to be regarded as 
a unit. 

To record these states, the “ quantities ” of JACK are particularly well suited. The 
direction of state changes is modelled by an ordering relation on the quantity space. E.g. 
for the press, the physical construction can be mirrored by defining “starting position 
precedes middle position” , etc. 

Tests are introduced by defining interaction units which generate requests to the user 
or the electronic control unit, respectively. Each reponse to a request causes actions, 
e.g. modifications of the internal structure or the introduction of a new interaction unit 
into the event queue. 

These extensions have been implemented in the DISA module, which contains a 
Constraint Definition Language (CDL) for the specification of generic components. 

DIAGTECH itself is a hybrid system consisting of DISA and DUCKITO. DUCKITO 
[13] is a logic-based “expert system” tool which allows to apply “compiled” diagnoses 
(in the form of rule sets) on the basis of empirical associations before trying the more 
complex DISA procedures which are operating on explicit descriptions. DIAGTECH 
has been completely implemented as described and is fully operational on IBM PCs 
(and compatibles). 

6 Discussion 

The limitations of knowledge-based diagnoses are given by the models in use. In general, 
multiple descriptions are required (cf. Davis [7]): A distinction between physical and 
functional information and between levels of abstraction as well as different categories 
of failure seems to be essential. 

The functional specifications we used are no “causal models” of these mechanisms. 
They only allow qualitative simulation to recognize discrepancies. 

The temporal extension of the DIAGMUFA algorithm points to fundamental diffi- 
culties. DIAGMUFA assumes non-directionality of the components and multiple values, 
i.e. simultaneous propagation in all possible directions. A temporal order does not allow 
to consider all “possible worlds” at once, but enforces an order on propagation. 

In general, the use of diagnosis systems based on explicit descriptions requires their 
embedding in an integrated design environment, where all necessary information is 
acquired during the design cycle of a technical system. Currently, the lack of suitable 
means for description is a decisive obstacle. 

In DISA, the treatment of conflicts, or inconsistency, as well as particular diagnostic 
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heuristics, were embedded into one algorithm. To guarantee the usefulness of the chosen 
approach in the long run, it should be generalized in a way that the recording and 
processing of inconsistency is performed by a separate general module. Indeed, as 
DeKleer [8] points out, most problem solvers search; if otherwise, a direct algorithm 
would solve the task. Then, two important problems are to be solved, namely, how the 
spaces of alternatives can be searched efficiently, and how the problem solver should 
be organized in general. DeKleer’s solution is convincing: On the one hand it is a 
consequent continuation of the “Truth Maintenance Systems” (TMS) line, which forces 
a clean division within a problem solver between a module solely concerned with rules 
of the domain and another module concerned with recording the current state of the 
search. While the first module draws inferences, the second, the TMS, records inferences 
(“justifications”). So, the TMS serves three roles: 

1. It serves as a “cache memory” for all inferences in that inferences, once made, 
need not be repeated. Inconsistencies, once detected, are avoided in the future. 

2. It allows the problem solver to draw non-monotonic inferences. If non-monotonic 
justifications are present, the TMS has to use a constraint satisfation procedure 
to determine what data are assumed to be valid. 

3. It assures that the data base is contradiction-free. The procedure of dependency- 
directed backtracking identifies and adds justifications to remove inconsistencies. 

DeKleer’s ATMS (Assumption Based TMS) [8] is a very efficient TMS module. In 
particular from our experience with DIAGTECH, but also from general considerati- 
ons about a logical extension to our object-oriented representation system, we decided 
to realize such a module within our framework as the next step of the FORK pro- 
ject. We believe this will be a mandatory prerequisite to address the perspective of 
logic programming, namely (predominantly descriptive) representation and processing 
of relations (constraints) and implications in the object domain, and, in particular, the 
representation and treatment of time in a more general way. The gap between a logical 
reconstruction of object-centered representations (cf. Nilsson [15]) and logic-based re- 
presentation systems with their inferential properties is still to be closed. Retrieval of 
complex descriptions requires a powerful extension to the well-known unifcation algo- 
rithms. The direction of this research is also influenced by our previous experience with 
DUCKITO, which contains a truth maintenance module and an explanation component 
on the basis of data dependences. 
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Expertensystem zur Anwendung neuer Werkstoffe 



B. Fehsenf eld, R. Küke, Th. Langer, B. Schönwald 
Krupp Forschungsinstitut, Essen 



Zusammenfassung 

Das vorgestellte Expertensystem unterstützt den Konstrukteur im 
Maschinen- und Anlagenbau bei der Auswahl geeigneter Bauteile, 
die unter technischen und wirtschaftlichen Gesichtspunkten 
anstelle von metallise en Werkstoffen durch Fas er Verbundwerk- 
stoffe realisiert werden können. Systemeingabe ist die Be- 
schreibung des metallischen Bauteils und der vorherrschenden 
Betriebsbedingungen. Systemausgabe ist eine Bewertung der Sub- 
stitutionsmöglichkeit des metallischen Werkstoffes durch den 
Faserverbundwerkstoff und eine detaillierte Beschreibung even- 
tueller Lösungsvorschläge. Das System ist hybrid aufgebaut. Für 
die Werkstoffdaten wurde eine deklarative Wissensrepräsentation 
durch Frames gewählt, während die prozeduralen Zusammenhänge 
durch ein Regelsystem dargestellt werden. 



Key-Words : Expertensysteme, Ingenieurwesen, Neue Werkstoffe 



1 Einleitung 

Neue Werkstoffe mit ständig verbesserten Materialeigenschaften 
drängen immer stärker aus dem Bereich der Grundlagenforschung 
heraus hin zu praktischen Anwendungen. Starke Forschungsakti- 
vitäten / 2 / auf Werkstoffgebieten wie Keramik, Pulvermetallur- 
gie und Faserverbundwerkstoffe, um nur einige zu nennen, unter- 
stützen diesen Vorgang zusätzlich. 

Für den Krupp-Konzern bietet sich neben der Werkstof f technik 
auch ein großes Potential von Einsatzmöglichkeiten im Maschi- 
nen- und Anlagenbau. Die Beurteilung des Einsatzes neuer Werk- 
stoffe im Maschinen- und Anlagenbau erfordert spezifisches 
Fachwissen, das im Bereich der Konstruktion und Planung des 
Maschinen- und Anlagenbaus nur selten zeitgerecht vorliegt. 
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Um dieses Defizit zu beheben, wurde vom Krupp Forschungsinsti- 
tut ein Expertensystem (ES) entwickelt, das den Konstrukteur 
und Ingenieur bei der Einführung neuer Werkstoffe berät. 

Nur mit der sich in den letzten Jahren immer stärker durch- 
setzenden Software-Technologie der Wissensverarbeitung konnte 
ein derart komplexes Problem überhaupt erfolgversprechend ange- 
gangen werden. 

Zum Einstieg in die Problematik der Anwendung neuer Werkstoffe 
wurden beim vorgestellten ES faserverstärkte Werkstoffe ge- 
wählt. Für diese Werkstof f gruppe liegen einerseits langjährige 
industrielle Erfahrungen vor, man denke nur an den Flugzeugbau 
und Leichtbau, wo dieser Werkstoff schon fast routinemässig 
eingesetzt wird? andererseits treten gerade im Maschinen- und 
Anlagenbau häufig Probleme der Krafteinleitung und Kraftführung 
auf, die mit diesem Werkstoff besonders gut gelöst werden kön- 
nen . 

Daß ein entsprechendes Potential für den Einsatz von Faserver- 
bundwerkstoffen vorliegt, zeigen bisher durchgeführte Reali- 
sierungen in diesem Bereich wie z.B. die kohlefaserverstärkte 
Drehspindel /5/, der kohlefaserverstärkte Roboterarm /6/ sowie 
die Entwicklung von glasfaserverstärkten Blattfedern für Nutz- 
fahrzeuge /4/. 

Mit dem entwickelten wissensbasierten System ist es möglich, 
unter den kraftführenden, metallischen Bauteilen potentielle 
Kandidaten für die Substitution durch Faserverbundwerkstoffe 
sowohl hinsichtlich ihrer technischen als auch ihrer wirt- 
schaftlichen Realisierung herauszufinden. Die Konzeption des 
Systems macht es möglich, gewonnene Erfahrungen, methodische 
Vorgehensweisen und einzelne Systembausteine auf andere inter- 
essante Werkstoffe, z.B. aus der Keramik oder der Pulvermetal- 
lurgie zu übertragen. 
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2 Faserverbundwerkstoffe 

Faser Verbundwerkstoffe bestehen aus Glas-, Aramid- oder Kohlen 
stof fasern, die in einer Kunststoff-Matrix eingebettet sind. 
Als Matrixmaterialien werden hauptsächlich Duroplaste einge- 
setzt, während sich Thermoplaste z.Z. noch im Stadium der Vor- 
versuche befinden. Ein Faserverbundwerkstoff besteht typischer 
weise aus einem Laminat ( d.h. einer Schichtstruktur, deren 
Einzelschichten unterschiedliche Faserorientierung besitzen 
können. Dieser Werkstof f verbünd besitzt mit 

- hoher spezifischer Festigkeit 
hoher Korrosionsbeständigkeit 

für den Maschinen- und Anlagenbau interessante Eigenschaften. 

Auslegung und Konstruktion von Bauteilen aus Faserverbundwerk- 
stoffen unterscheiden sich deutlich von den entsprechenden 
Methodiken mit metallischen Werkstoffen. Der Konstrukteur kann 
nicht auf eine überschaubare Palette erprobter Werkstoffe zu- 
rückgreifen, er muß durch geschickte Wahl von Faser und Matrix 
sowie eines geeigneten Laminataufbaus die Werkstoffeigenschaf- 
ten vollständig auf den vorliegenden Problemfall abstimmen. 

Außerdem muß schon während der Konstruktionsphase berücksich- 
tigt werden, daß eine Fertigung des Bauteils möglich ist. In 
den Abb. 1 bis 3 / 3/ werden die für Faserverbundwerkstoffe 
gängigen Fertigungsverfahren schematisch vorgestellt. Die dar- 
gestellten Fertigungsmöglichkeiten üben starke Restriktionen 
auf die Konstruktion aus, die es zu berücksichtigen gilt. 

Es wird deutlich, daß die Substitution eines metallischen Bau- 
teils durch ein Bauteil aus Faserverbundwerkstoff ein weit 
gefächertes Spezialwissen erfordert. Dieser stark ineinander- 
greifende Prozeß, der während der Entscheidungsfindung abläuft 
wurde durch das vorgestellte wissensbasierte System nachgebil- 
det . 
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3 Wissensrepräsentation im Expertensystem 

Die Implementation von Expertensystemen (ES) erfordert Hard- 
ware- und Software-Unterstützung in einem Maße/ das den übli- 
chen Rahmen des Software-Engineerings sprengt. Die Lisp-Ma- 
schine Symbolics 3645 als Hardware liefert den notwendigen 
Bedienungskomfort wie Window-Technik/ Menü-Technik/ Mouse-Hand- 
ling, Debugging und Multi-Tasking sowie mit Lisp eine zum Zweck 
des ES-Designs beliebig erweiterbare Grundsprache /8/ . 

Von entscheidender Bedeutung für effizienten Aufbau und Wartung 
eines ES ist eine starke Software-Unterstützung bei der Wis- 
sensrepräsentation. Die Übertragung von Wissensstrukturen muß 
dabei möglichst direkt und zwanglos stattfinden. 

Die wesentlichen Wissensstrukturen bestehen beim entwickelten 
ES in 

- taxonomischem Wissen und 

- assoziativem Wissen. 



3.1 Taxonomische Wissensstruktur 



Als Organisationsstrukturen/ die taxonomisches Wissen enthal- 
ten, bieten sich adressierbare Objekte (Frames) an. Zwischen 
den Objekten bestehen Hierarchiebeziehungen, die in der Verer- 
bung von Objekteigenschaften aus einer Objektklasse in eine 
andere Ausdruck finden können. Unterhalb der Klassen liegt die 
Objektinstanzebene, die zu jedem Zeitpunkt ein aktuelles Ge- 
samtbild des Zustandes der Wissensbasis repräsentiert und durch 
Regelzugriff dynamisch veränderbar ist. 

Beispiele für taxonomische Wissensstrukturen in der Wissensba- 
sis sind z.B. die Materialdaten, die Beschreibung des zu sub- 
stituierenden Bauteils (z.B. Geometrie (Abb. 4)) und der zur 
Verfügung stehenden Fertigungsverfahren. Auch die Beschreibun- 
gen der Substitutionsvorschläge des Systems sind in dieser 
Weise strukturiert. 
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Abb. 4: Objektklassenhierarchie für die Bauteilgeometrie 



3.2 Assoziative Wissensstruktur 



Unter assoziativem Wissen ist die Verknüpfung von in Objekten 
abrufbaren Sachverhalten zu verstehen. Im weiteren Sinne zählen 
hierzu sowohl das Wissen über strategische Vorgehensweisen, 
Kontrollen über die Verträglichkeit von Objektzuständen (Con- 
straints) als auch einfache wenn-dann Regelbeschreibungen. 

Ist die Kontrollstruktur für die Abarbeitung des Wissens vom 
ES-Designer beeinflußbar, so können alle Aspekte der assoziati- 
ven Wissensstruktur mit dem Produktionsregelparadigma beschrie- 
ben werden. Produktionsregeln erfragen in ihren Prämissen Ob- 
jektzustände und können im Aktionsteil andere Objektzustände 
modifizieren bzw. über Lisp-Code Seiteneffekte anderer Art 
(Grafik, Berechnungen, Beschneidung von Suchbäumen) auslösen. 
Mit dieser Technik wird das gesamte dynamische Wissen abgebil- 
det (z.B. Werkstof f auswahl , Dimensionierungsstrategie, Wahl des 
geeigneten Fertigungsverfahren, Wirtschaf tlichkeitsbetrachtun- 
gen) . (Beispiele: Abb. 5) 
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: Rule-Set Faserauswahl 

Rule-201 
IF $and 

(aktuelle-Bauteil-Vorgaben Wärmeausdehnung = gering) 

Then $ Conclude 

(Nur-behalten-in »Faserliste» 'Fasertyp 'Equal 'Kohlefaser) 



: Rule-Set Verträglichkeit 

Rule-312 

IF $and 

(Greatep (»-»Faser* :get 'Bruchdehnung) 

(»-»Harz* :get 'max. Bruchdehnung) 

Then $ Conclude 

(Stop-Execution) 



Abb. 5: Beispiele für Produktionsregeln 



Die grundlegenden Forderungen an ein Software— Tool zur Erstel- 
lung von Wissensbasen werden von der ES-Shell Babylon der Ge- 
sellschaft für Mathematik und Datenverarbeitung erfüllt /1,7/. 
Es bietet in seiner gegenwärtigen Form außerdem den Vorteil des 
freien Zugriffs auf den Quell-Code. 



4 Design des Expertensystems 

Abb. 6 zeigt die grobe Gliederung des ES, das aus zwei Haupt- 
teilen, Benutzereingabe und Expertise, besteht. 
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Abb. 6: Eingabe- und Ablauf schema für das Expertensystem 



4 . 1 Benutzereingabe 

Im ersten Schritt spezifiziert der Benutzer das zu substituie- 
rende Bauteil in bezug auf seine geometrische Form, konstrukti- 
ve Besonderheiten und die Bauteilbeanspruchung (mechanisch, 
physikalisch, chemisch). 
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Nach der Beschreibung des Metallbauteils wird vom Benutzer 
das Substitutionsziel konkretisiert: Erwünschte und unerwünsch- 
te Bauteileigenschaften, beabsichtigte Eigenschaf tsverbesserun- 
gen im Vergleich zum metallischen Bauteil, eventuelle Randbe- 
dingungen wie Stückzahl oder Durchsatz. Plausible Grundannahmen 
werden vom ES vorgeschlagen. Von entscheidender Bedeutung ist 
dann die Definition der unveränderbaren Randbedingungen (z.B. 
einzuhaltende Maße). Schließlich spezifiziert der Benutzer, 
welche mechanische Eigenschaft des metallischen Bauteils für 
dessen Funktionalität entscheidend ist. Diese Eingabe bildet 
die Hauptinformation für die ablaufende Expertise. Das ES ist 
in jedem Zustand mit einer Erklärungskomponente versehen. 



4 . 2 Expertise 

Nach der Benutzereingabe kann die Expertise hinsichtlich der 
Substituierbarkeit des Bauteils gestartet werden. Im Sinne 
eines Truth-Maintainance-Verfahrens werden zuerst die Benutzer- 
eingaben auf Stimmigkeit überprüft und aus dem Fundus der in 
eine interne Datenbank eingetragenen Materialien (Fasern und 
Harze) solche Komponenten ausgewählt, die mit allen Vorgaben 
verträglich sind. Ebenso werden Fertigungsverfahren nach ihrer 
Tauglichkeit für die gestellte Substitutionsaufgabe bewertet 
und geordnet. 

Der verbliebende Suchraum (Faser-Harz-Fertigungs-Kombinationen, 
jeweils zu untersuchen auf Dimension, Fertigbarkeit , Kostenauf- 
wand usw. ) wird durch eine heuristische Suchstrategie einge- 
grenzt, die aus einer Kombination von Suche in die Tiefe und 
Suche in die Breite besteht. V7ichtigstes Kriterium bei der 
Suche nach Substitutionsvorschlägen ist die technische Reali- 
sierbarkeit? wirtschaftliche Gesichtspunkte werden erst berück- 
sichtigt, wenn die technische Realisierbakeit gesichert ist. 
Ergebnis der Expertise des Systems ist eine Liste von möglichen 
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Substitutionsvorschlägen, die in bezug auf vom Benutzer vorge- 
gebene Kriterien bewertet und geordnet ist. Zu jedem ausgewie- 
senen Substitutionsvorschlag ist eine ausführliche Beschreibung 
und Begründung abrufbar. Die Beschreibung der Substitutionsvor- 
schläge enthält Aussagen übers 

- Faser- und Harzmaterial 
Abmessungen des substituierten Bauteils 

phys . -ehern. -mechan . Eigenschaften des substituierten 
Bauteils (auf Wunsch im Vergleich zum metallischen 
Bauteil ) 

- Aufbau und Struktur des Laminates 
Fertigungsverfahren für das Laminat 

Kostenabschätzung für die Fertigung eines Bauteils. 

Zur Begründung der vorgeschlagenen Lösung werden die während 
des Lösungsweges verwendeten Regeln auf gelistet. Jede dieser 
Regeln kann vom Benutzer inspiziert werden. 

Findet das Expertensystem keine Möglichkeit zur Substitution, 
wird dieses dem Benutzer zusammen mit den Regeln, auf die die 
Systementscheidung zurückgeht, kenntlich gemacht. 



5 Zusammenfassung und Ausblick 

Die Fragestellung, ob ein kraftführendes metallisches Bauteil 
durch Faserverbundwerkstoff substituiert werden kann, ist im 
Maschinen- und Anlagenbau von grundlegender Bedeutung. Das 
vorgestellte ES unterstützt den dort tätigen Konstrukteur und 
Ingenieur bei der Bearbeitung dieser Fragen in effektiver 
Weise . 

Das System kann in zwei Richtungen weiterentwickelt werden. Zum 
einen können die Wissensbereiche Werkstof fdaten , Dimensionie- 
rung, Fertigung und Wirtschaftlichkeit in ihrer Informations- 
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und Wissenstiefe erweitert werden, um über die Substitution 
hinausgehende Anwendungen zu erschließen: z.B. Auswahl von 
verträglichen Fasern und Harzen, Feindesign oder fertigungs- 
technisches Know-how von Bauteilen» Zum anderen kann das System 
auch für Beratungs- und Schu lungs zwecke ausgebaut werden, und 
zwar zur Unterstützung des Konstrukteurs und Ingenieurs, der 
mehr mit herkömmlichen, metallischen als mit neuen Werkstoffen 
wie z.B. Faserverbundwerkstoffen vertraut ist. Zur Zeit wird 
geklärt, welchem dieser Wege Priorität eingeräumt wird. 

Über den Faserverbundwerkstoff hinaus kann das Expertensystem 
um weitere Werkstoffe erweitert werden. Im nächsten Schritt 
wird daher der Werkstoff Keramik integriert, wobei einzelne 
Systembausteine wie z.B. Benutzerschnittstellen, Daten- und 
Methodenbanken wiederverwendet werden können. 
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KRITON: 

Wissensakquisition für Expertensysteme 

Joachim Diederich, Mark May, Ingo Ruhmann; GMD, St. Augustin 



Zusammenfassung: Es wird ein Modell zur automatischen und halbautomati- 
schen Akquirierung von Experten wissen vorgestellt, das Verfahren aus dem Bereich 
des Knowledge Engineering und der Kognitions Wissenschaft kombiniert. In diesem in- 
tegrierten Ansatz werden, je nach Art des zu akquirierenden Wissens, den einzelnen 
Methoden konkrete Anwendungsbereiche zugeordnet. So werden automatisierte Inter- 
viewtechniken und textanalytische Verfahren zur Akquirierung von deklarativem Wis- 
sen eingesetzt, während die Analyse von Protokollen lauten Denkens während einer 
Problemlösung zum Erwerb prozeduralen Wissens verwandt wird. Die Zielstruktur der 
Wissenserwerbsmethodenist die Zwischenrepräsentation auf der Regel- und Framegene- 
ratoren operieren um eine Wissensbasis in der angestrebten endgültigen Form zu erzeu- 
gen. Die Ebene der Zwischenrepräsentation reguliert und steuert weiterhin den Einsatz 
der Wissenserwerbs verfahren. Unvollständiges Wissen wird durch den knowledge base 
watcher “entdeckt” und es werden automatisch adäquate Erwerbsmethoden aktiviert 
um notwendiges Wissen zu ergänzen und vorhandenes Wissen weiter zu spezialisieren. 

1. Einleitung 

Mit dem hier vorzustellende Wissensakquisitionssystem KRITON wird versucht, 
wesentliche Teile des Wissenserwerbsprozesses im Aufbau wissensbasierter Systeme zu 
automatisieren und den Wissensingenieur diesbezüglich zu entlasten. Es gehört zu 
den grundlegenden Annahmen KRITONs, daß keine einzelne Akquistionsmethode al- 
leine mächtig genug ist, um den sogenannten “knowledge acquisition bottleneck” zu 
überwinden und somit ein wesentliches Hindernis für praktischen Einsatz von Exper- 
tensystemen im industriellen Umfeld zu beseitigen. Zur Aufhebung dieses Engpasses 
bedarf es hybrider Wissensakquisitions- Werkzeuge, die unterschiedliche Erwerbsmetho- 
den einsetzen um verschiedene Arten des Expertenwissens zu erfassen. 

Es lassen sich prinzipiell zwei bedeutsame Wissensquellen unterscheiden, von 
denen Expertenwissen akquiriert werden kann: 

1. Den menschlichen Experten mit seinem deklarativen und prozeduralen Wissen 
über das betreffende Sachgebiet. Dieses Wissen, das zumeist auf mehrjährige 
Erfahrung und Anwendung zurückgeht, wird vom Experten häufig ohne ausrei- 
chendes Meta- Wissen über die Art und Weise seiner Verwendung eingesetzt. Die 
Problemlöseprozesse zu modellieren, die auf diesem häufig unvollständigen und 
unstrukturierten Wissen aufbauen, ist eine Aufgabe, die Expertensystemen zu 
bewältigen haben. 
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2. Wissen, das bereits in natürlich-sprachlichen Dokumenten, Handbüchern, techni- 
schenBeschreibungen und Anleitungen fixiert ist. In vielen Fällen liegt Wissen, das 
für Expertensysteme relevant wird, bereits in dieser Form vor. Natürliche Sprache 
ist die “traditionelle” Wissensrepräsentationssprache. 

Ziel dieser Arbeit ist es, einen integrierten methodischen Ansatz vorzustellen, der den 
verschiedenen Formen des Expertenwissens Rechnung trägt (deklaratives vs. prozedu- 
rales Wissen) und methodische Verfahren unterschiedlicher Provenienz in einem modu- 
laren Wissensakquisitionssystem vereint. Jedes dieser einzelnen Verfahren sollte dabei 
in der Lage sein, bestimmte Aspekte des Problemlösungsprozesses zu erfassen und in 
einen Wissensrepräsentationsformalismus zu überführen. 

In KRITON werden Methoden des Knowledge Engineering, wie sie zur Zeit prak- 
tiziert werden, und Vorgehensweisen aus dem Bereich der Kognitionswissenschaften 
miteinander kombiniert. Zu den derzeitigen ad-hoc Strategien des Knowledge Enginee- 
ring zählt das Interview, also der Dialog zwischen Wissensingenieur und Experte, um 
wichtige Begriffe und Konzepte eines Problembereichs sowie deren Zusammenhang zu 
erfragen. Aus dem Bereich der Kognitionswissenschaft stammt die Protokollanalyse, 
d.h. die Verarbeitung und Transformierung von Texten, die durch Transskription von 
Protokollen “lauten Denkens” während einer Problemlösung gewonnen wurden. Die 
Analyse dieser Protokolle wurde innerhalb der Künstlichen Intelligenz schon recht früh 
automatisiert [18]. 

Ebenfalls in den Bereich der Kognitionswissenschaft gehört die Analyse von Tex- 
ten hinsichtlich syntaktischer, semantischer und pragmatischer Kriterien. In den Sozial- 
wissenschaften ist die Inhaltsanalyse inzwischen zur Standardmethode gereift und stellt 
eine bisher weitgehend ungenützte Möglichkeit für den Erwerb von Wissen auf der Basis 
von natürlich-sprachlichen Texten dar [12]. In KRITON wird eine Art inkrementeile 
Textanlyse eingesetzt, um von dieser wertvollen Wissensquelle Gebrauch zu machen. 

KRITON ist ein interaktives System, das die Benutzung sowohl durch einen Wis- 
sensingenieur, als auch durch einen Bereichexperten vorsieht. Die Wissenserwerbs ver- 
fahren Interview und inkrementelle Textanalyse erlauben die direkte Interaktion des 
Experten mit dem Wissensakquisitionssystem. Die Benutzung der weiteres Teile des 
Systems, insbesondere die semi-automatische Generierung der entgültigen Wissensba- 
sis, sollte durch einen Wissensingenieur mit KI-Kenntnissen geschehen. Die adäquate 
Anwendung der Protokollanalyse (insbesondere der Protokollaufnahme) erfordert zu- 
dem psychologische Kompetenz. 

Abbildung 1 zeigt die grundlegende Architektur des KRITON-Systems. Gezeigt 
sind die drei (semi- Automatisierten Wissensakquisitionsmethoden Textanalyse, Proto- 
kollanalyse und Interview. Nach einem Vervollständigungsprozess und einer Konsistenz- 
überprüfung wird die erworbene Information in eine Zwischenrepräsentationssprache, 
bestehend aus einer Beschreibungssprache für funktionale und physikalische Objekte so- 
wie einem propositionalen Kalkül, übersetzt. Frame- und Regelgeneratoren, welche auf 
der Zwischenrepräsentationssprache operieren, werden herangezogen, um die endgültige 
Wissenbasis aufzubauen. 

Auf der anderen Seite unterstützt das bereits akquirierte Wissen den Wissens- 
erwerbsprozess, indem es den Einsatz der Erwerbsmethoden direkt steuert um un- 
vollständiges Wissen zu ergänzen. In diesem Sinne kann von einer inkrementeilen Ver- 
vollständigung der Wissensbasis gesprochen werden. 
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Abb. 1: Die KRITON- Architektur 



2. Methoden der Wissensakquisition 

Auf der ersten Verarbeitungsebene setzt das System drei verschiedene Wissen- 
serwerbsmethoden ein, auf die im folgenden näher eingegangen wird. 

2.1. Interview 

Zu den Hauptstrategien des Knowledge Engineering kann das Interview gerech- 
net werden. Grover [8] unterscheidet vier verschiedene Interviewtechniken für die Wis- 
sensakquisition: 
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1. forward scenario simulation 

Unter Laborbedingungen wird eine Anwendungssituation innerhalb des gesamten 
Problembereichs ausgewählt und vollständig zu eruieren versucht. Dabei beschreibt 
der Experte seine Vorgehensweise, d.h. seine eigenen Denkprozesse (reasoning) um 
ein bestimmtes Ziel zu erreichen. 

2. goal decomposition 

Das Gesamtproblem wird vom Wissensingenieur in Teilbereiche und Unterziele 
gliedert und der Experte wird aufgefordert, Wege zum Erreichen dieser Subziele zu 
beschreiben. 

3. procedural simulation 

Unter dieses Stichwort faßt Grover [8] die Protokollanalyse, wobei er steuernde 
Eingriffe des Wissensingenieurs für unabdingbar hält. 

4. pure reclassification 

Beobachtungen durch den Experten werden durch den Dialog Wissensingenieur - 
Experte sukzessiv eruiert und weiter differenziert um das Wissen in spezifische 
Objekte und deren Relationen zu enkodieren. Gegebenenfalls werden Beziehungen 
zwischen Objekten auch reklassifiziert. 

Eine Interviewtechnik, die nicht in Grover’s Klassifikation genannt wird, ist das 

5. laddering 

Wichtige Konzepte des Problembereichs werden vom Experten erfragt und zur 
Grundlage des weiteren Interviews gemacht. Insbesondere Supertypen und Instan- 
zen von generischen Konzepten werden erfragt, um eine taxonomische Struktur zu 
bilden. Eine automatisierte Form dieser Interviewtechnik wurde, unter Rückgriff 
auf weiterentwickelte Methoden von Kelly ([10], [16], [17]), in ETS (Expertise 
Transfer System; [4]) realisiert. 

2.2. Interviewmethoden in KRITON 

In KRITON sind die Interviewtechniken vollständig automatisiert, das heißt, 
der Experte interagiert mit dem System direkt. Um die bedeutsamen Konzepte eines 
Problemgebiets zu explorieren, werden Konstruktgitter- Techniken (repertory grid; [10]) 
mit solchen des Forward Scenario Simulation und des Laddering kombiniert. 

Auf der obersten Ebene gestaltet sich das Interview als Konstruktgitteransatz: 
dem Experten werden Tripel semantisch verwandter Konzepte, eingebettet in einen 
natürlich-sprachlichen Satz, vorgegeben und er wird gebeten Attribute (Konstrukte) zu 
benennen, in denen sich je zwei der Konzepte gleichen, sich aber gleichzeitig vom dritten 
unterscheiden. 

Ist der Experte nicht in der Lage, diskriminierende Attribute zu nennen, schal- 
tet das System in einen Laddering-Modus, um taxonomische Relationen zwischen den 
betreffenden Konzepten abzufragen. Im Interview hat der Experte die Möglichkeit, ent- 
weder mit einem einzelnen Wort (Konzept) zu antworten oder freien Text einzugeben, 
welcher mithilfe von morphologisch-syntaktischen Techniken auf relevante Konzepte hin 
untersucht wird. Das Interview generiert strukturierte Objekte auf der Ebene der Zwi- 
schenrepräsentationssprache. In diesen Objekten sind die vorher explorierten Attribute 
und taxonomischen Relationen festgehalten. 
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2.3. Protokollanalyse 

Protokpllanalyse ist der feststehende Ausdruck für die automatische oder halb- 
automatische Analyse von Protokollen lauten Denkens. Diese Protokolle werden mei- 
stens in Form von Tonbandaufzeichnungen der Verbalisierungen eines Experten während 
einer tatsächlichen Problemlösung festgehalten. Das Resultat der Protokollanalyse kann 
als Pfad durch Wissensstadien im Problemraum aufgefaßt werden, und repräsentier tda- 
mit den Problemlöseprozeß des menschlichen Experten. Benutzt ein Expertensystem 
diese Sequenz von Wissensfragmenten im Inferenzprozeß (z.B. in einer Beratung) so 
findet eine Oberflächenmodellierung (surface modelling) des menschlichen Problemlöse- 
prozesses statt. 

Obwohl eine automatische Protokollanalyse als Verfahren zur Wissensakquisition 
für Expertensysteme seit einiger Zeit als adäquate Methode propagiert wird, liegen aus- 
gereifte Systeme bisher nicht vor. Eine in sich konsistente Vorgehensweise wird von 
Kuipers & Kassirer [11] beschrieben. Ziel der von ihnen vorgeschlagenen Protokoll- 
analyse ist sowohl eine strukturale Beschreibung des Problembereichs, als auch eine 
qualitative Simulation der Übergänge zwischen Wissenszuständen während des Pro- 
blemlöseprozesses. Dabei verwenden sie eine Constraint-Sprache, um unvollständige 
Protokollsegmente mit erschlossener Information zu ergänzen. 

Die Mächtigkeit der Protokollanalyse hängt entscheidend von der Qualität der 
Protokollaufnahme ab. Nur wenn es sich bei den Protokollen um die Transskription ei- 
nes relativ reinen lauten Denkens während einer Problemlösung handelt und nur wenn 
diese Protokolle korrekt transskribiert wurden, verspricht die automatische Analyse er- 
folgreich zu sein. Darum bedarf es detaillierter Instruktionen um die Prozedur des 
“lauten Denkens” kontrolliert durchführen zu können, mit dem Ziel eine gleichmässig 
hohe kognitive Auslastung des laut denkenden Experten zu erreichen. 

Einen Überblick über methodische Probleme im Zusammenhang mit der Analyse 
verbaler Daten geben Ericsson &: Simon [6] und Huber & Mandl [9]. 

Die Frage der Granularität des Expertenwissens hat sich als ernsthaftes Problem 
bei der Wissensakquisition erwiesen. Selbst bei sorgfältigster Durchführung der Proto- 
kollaufnahme wird es unvermeidbar sein, daß problem-irrelevante Wissenselemente in 
die automatische Analyse eingehen. Dieses ist z.B. der Fall, wenn der Experte seine 
eigenen Gedanken und Handlungen kommentiert, erklärt oder bewertet. 

Das andere Extrem kann ebensogut auftret en, wenn der Experte dem System sein 
“kompiliertes Wissen” [1] mitzuteilen versucht. Beim Experten werden während sei- 
nes Lernprozesses einzelne Inferenzschritte zusammen gef aßt, sodaß Stadien in der Pro- 
blemlösung übersprungen werden. Auch wenn dieses nicht den Erfolg des zukünftigen 
Expertensystems beeinträchtigt, so doch die Erklärbarkeit des Problemlöseprozesses. 

2.4. Protokollanalyse in KRITON 

Protokollanalyse wird in KRITON vorwiegend benutzt um prozedurales mensch- 
liches Wissen zu akquirieren. Wissen, das vorher Teil eines Interviews oder der Text- 
analyse war, wird während der Protokollaufzeichnung “in Aktion” beobachtet. Ziel- 
struktur für die Protokollanalyse ist der propositionale Teil der Zwischenrepräsenta- 
tionssprache. In KRITON lassen sich bei der Protokollanalyse fünf Schritte unterschei- 
den: zunächst werden die transskribierten Protokolle nach Einschätzung der Sprechpau- 
sen des Experten in Segmente aufgeteilt. Der zweite Schritt ist die semantische Analyse 
der einzelnen Segmente, d.h die Generierung von Operator-Argument Strukturen. Im 
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dritten Schritt wird die Angemessenheit der ausgewählten Operatoren und Argumente 
überprüft. Als nächstes wird eine Vervollständigung (knowledge base match) versucht, 
um Variablen innerhalb der Operator- Argument Strukturen zu beseitigen (Variablen 
werden an den Stellen eingefügt, wo Referenzen nicht aufgelöst werden können). Im 
fünften und letzten Schritt werden die Operator- Argument Strukturen entsprechend 
ihrem chronologischen Auftreten im natürlich- sprachlichen Text geordnet. 

2.5. Text analyse 

Phasenmodelle der Wissensakquisition legen es dem Wissensingenieur nahe, seine 
Arbeit mit der Lektüre bzw. dem Studium der Handbücher und einschlägigen Literatur 
des infragestehenden Problemgebietes zu beginnen. Dies kann sehr zeitintensiv sein, 
insbesondere wenn der Wissensingenieur erst zum Experte werden soll, bevor er mit 
seiner eigentlichen Arbeit beginnt. Seit annähernd 40 Jahren werden inhaltsanalytische 
Methoden zur Analyse von Texten, speziell von Zeitungsartikeln eingesetzt. 

Seit den fünfziger Jahren existieren Programme zur automatischen Text analyse 
[12]. Der Einsatz dieser Methoden für die Entwicklung wissensbasierter Systeme wird 
in der Literatur vereinzelt beschrieben ([15], [7]). 

2.6. Textanalyse in KRITON 

KRITON unterstützt den Wissensingenieur bei der inkrementeilen Textanalyse. 
Es stellt statistische Informationen über die Vorkommenshäufigkeit bestimmter Stich- 
wörter im Text bereit. Erscheint die Analyse eines Textes für die Wissensakquisition 
lohnenswert, kann der Benutzer einen bestimmten, die Stichwörter umgebenden Be- 
reich definieren, welcher, ähnlich wie bei der Protokollanalyse, als Grundlage für die 
Generierung von Operator- Argument Strukturen dient. 

Die resultierenden propositionalen Strukturen sind oft fehlerbehaftet, sodaß sie 
sich nicht unmittelbar als Basis für Inferenzprozesse eignen. Die Zwischenrepräsenta- 
tion wird in einem interaktiven Prozeß aufgebaut, in welchem dem Benutzer potentielle 
Objekte und Relationen in einem Menü- und Fenster- System offeriert werden. Durch 
Auswahl der entsprechenden Items via Maus- Operationen kann die Wissensbasis suk- 
zessive aufgebaut werden. 

3. Zwischenrepräsentation 

Der gesamte Output der obengenannten Wissensakquisitionstechniken wird in 
eine Zwischenrepräsentationssprache übersetzt. Dieses Repräsentationssystem besteht 
aus zwei Teilen, einer Beschreibungssprache für funktionale und physikalische Objekte , 
in welchem die generischen Konzepte repräsentiert sind, und einem propositionalen 
Kalkül , das den Transformationspfad dieser Konzepte während des menschlichen Pro- 
blemlöseprozesses ab bildet. Der deklarative Teil der Zwischenrepräsentation besteht 
aus strukturierten Objekten, deren Attribute und Interrelationen ein semantisches Netz 
bilden. Dieses semantische Netz ist Zielsprache für die Methoden Interview und Text- 
analyse und dient als Basis für den Frame- Generierungsprozeß. 

Den zweiten Teil der zwischengeschalteten Repräsentationssprache bilden Opera- 
tor-Argument Strukturen um die in der Protokollanalyse gefundenen Beziehungen zwi- 
schen den Konzepten zu beschreiben. Auf diesem Weg soll also der Pfad durch den 
Problemraum während der Problemlösung beschrieben werden. Zum einen erlaubt 
die zwischengeschaltete Repräsentationsebene die Integration von Wissen aus verschie- 
denen Quellen und verleiht dem Werkzeug damit Offenheit hinsichtlich zukünftig zu 
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entwickelnder Erwerbsmethoden. Zum anderen kann sie dazu dienen, Wissensbasen für 
verschiedene Expertensystem-Shells bzw. Wissensrepräsentationssysteme zu generieren. 

4. Wissensgesteuerter Wissenserwerb 

Wann welche Wissensakquisitionsmethoden eingesetzt werden, hängt nicht nur 
vom Wissensingenieur ab, sondern auch davon, welchen Bedarf an weiter zu explorie- 
renden Begriffen KRITON auf der Basis des bereits gewonnenen Wissens diagnosti- 
ziert. Eine bedeutsame Rolle beim Umgang mit unvollständigem Wissen spielt der so- 
genannte knowledge base watcher (im weiteren “Watcher”). Der Watcher ist ein ständig 
aktives Programm, das die zwischengeschaltete Wissensrepräsentation auf fehlende Ele- 
mente hin kontrolliert. Wenn beispielsweise der Benutzer (Experte oder Wissensin- 
genieur) während der inkrementeilen Textanalyse verschiedene neue Objekte generiert 
hat ohne daß diese in einer Beziehung zur taxonomischen Organisation der definierten 
Objekte des Inhaltsbereichs stehen (mit anderen Worten: es liegen keine Informatio- 
nen über Vererbungsrelationen, Teil- von- Beziehungen oder Instanz-Beziehungen vor), 
dann überprüft der Watcher alle Objekte auf der Zwischenrepräsentationsebene nach 
fehlenden, möglichen oder notwendigen Relationen (jedes Objekt muß in einer taxono- 
mischen Struktur verankert sein), benachrichtigt den Benutzer hierüber und invoziert 
den Einsatz bestimmter Akquisitionsmethoden um die Wissensbasis zu komplettieren. 
Zu Beginn des Einsatzes einer Akquisitionsmethode informiert der Watcher den Benut- 
zer über Lücken in der Wissensbasis. Außerdem kann der Benutzer die Auswahl, der 
in einem Interview zu erforschenden Konzepte, an den Watcher delegieren. In diesem 
Falle sucht das Programm nach semantisch verwandten, aber unvollständigen Objekten 
und steigt z.B. an der adäquaten Stelle in ein Interview ein, um das Gebiet weiter zu 
explorieren (unvollständiges Wissen zu ergänzen und vorhandenes weiter zu spezialisie- 
ren). 



5. Generierung der Wissensbasis 

Wie oben bereits erwähnt, dient die Zwischenrepräsentationssprache als “black- 
board” für die Regel- und Framegenerierung. 

Aufgabe des Frame- Generator ist es, die in den strukturierten Objekten und 
deren Relationen untereinander abgelegten Informationen in eine Frame- Sprache zu 
übersetzen. Im Prinzip handelt es sich hierbei um einen einfachen syntaktischen Trans- 
formationsprozeß. Nach der Frame- Generierung hat der Benutzer die Möglichkeit, das 
Ergebnis der Übersetzung mit einem Struktureditor interaktiv zu korrigieren. 

Der Output der Protokollanalyse ist der Input für den Regelgenerator. Eine 
Gruppe von proposition alen Klauseln, die aus aufeinanderfolgenden Segmenten des Pro- 
tokoll lauten Denkens extrahiert wurden, wird dem Benutzer zur Regel-Generierung an- 
geboten. Der Benutzer kann die vorgeschlagenen Operator- Argument Strukturen ent- 
weder zurückweisen oder zur Regelgenerierung heranziehen. Die gesamte Interaktion 
der Regelgenerierung vollzieht sich über maus-sensitive pop-up Menus. Durch einen 
Regeleditor können eventuelle Fehler der Protokollanalyse verbessert werden. 

6. Phasen des Wissenserwerbs in KRITON 

Im folgenden sind die einzelnen Phasen der Wissensakquisition in KRITON dar- 
gestellt, wobei die einzelnen Schritte nicht streng chronologisch durchlaufen werden 
müssen. Insbesondere durch den Einfluß des wissensgesteuerten Akquisitionsprozesses 
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sind Schleifen, d.h. wiederholter Einsatz von verschiedenen KRITON-Submethoden, 
wahrscheinlich und bei größeren Anwendungen sicherlich auch notwendig. Auf der an- 
deren Seite wird in bestimmten Fällen auch der exklusive Gebrauch einzelnen 

Submethode erfolgreich sein. Auf die Technik der inkrementeilen Textanalyse wird in 
zukünftigen Publikationen detaillierter eingegangen. 

Insgesamt lassen sich drei Ebenen des Wissensakquisitionsprozesses unterschei- 
den: die Phase der Wissensextraktion (elicitation), die Ebene der Zwischenrepräsenta- 
tion und die Generierung der Wissensbasis. 

Die Phasen III bis XI thematisieren im wesentlichen die Anwendung der Proto- 
kollanalyse. Zur näheren Erläuterung wird ein sehr kurzes Beispiel für ein natürlich- 
sprachliches Protokoll (lediglich eine Expertenäußerung) angegeben und der automati- 
sche Analyseprozeß anhand dieses Beispiels nachvollzogen. Das zu analysierende Pro- 
tokoll kann natürlich beliebig lang sein. 

Die Phasen I (Definition des Problembereichs), III (Protokollaufnahme) und IV 
(Transskription) können nicht automatisiert werden. Alle anderen Phasen sind vollau- 
tomatisiert, lediglich die Regel-Generierung vollzieht sich in einem interaktiven Prozeß. 

I. Definition des Problemraums 

Das aktuelle Wissensgebiet, definiert durch die Situation in der der menschli- 
che Problemlösungsprozeß stattfindet, wird zu Anfang mithilfe von Interviewtechniken 
eruiert. Die Definition des Wissensgebiets und die Aufsplittung des umfangreichen Ex- 
pertenwissens in wohlproportionierte Unterteile stellt eine wichtige Vorbedingung für 
das Gelingen der späteren automatischen Akquisitionsmethoden dar. 

IL Erwerb von deklarativem Wissen mittels automatischer Interviewtechniken 
und inkrementeller Textanalyse 

Wichtige Begriffe und Konzepte eines konkreten Wissensgebiets, welche später 
mithilfe der Protokollanalyse oder anderer Methoden für prozedurales Wissen unter- 
sucht werden sollen, werden zunächst exploriert und in das computergestützte Analy- 
sesystem eingegeben. Interview und Textanalyse werden solange zyklisch eingesetzt, bis 
das Netz der strukturierten Objekte eine angemessene Größe erreicht hat. 

III. Protokollaufnahme unter Anleitung 

Ein Protokoll lauten Denkens wird mithilfe eines Tonbandgeräts aufgezeichnet. 
Dieses erfordert eine sorgfältige Anleitung, um ständige Verbalisierung des Experten 
während seiner Arbeit (dem Problemlösungsprozeß) zu gewährleisten. Mehrere Proto- 
kolle sind notwendig, soll der Problemraum nicht auf einen einzelnen Problemlösungs- 
pfad beschränkt bleiben. 

IV. Transskription 

Das Protokoll wird transskribiert. Sprechpausen während der Protokollaufnahme 
werden bei der Transskription markiert, Satzzeichen werden nicht verwendet. Das Pro- 
tokoll wird in das Analysesystem eingegeben. 

wenn das Oel braunverbrannt ist ** dann sind Kupplung und 

Bremsbänder beinträchtigt 

Eine kurze Expertenäußerung im natürlich-sprachlichen Protokoll 
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V . Segmentierung des Protokolls 

Das Protokoll wird in einzelne durchnummerierte Segmente unterteilt, wobei die 
Sprechpausen die Länge der Segmente determinieren. 

(Dl wenn das Oel braun verbrannt ist) 

(D2 dann sind Kupplung und Bremsbänder beinträchtigt) 

Das segmentierte Protokoll 



VI. Semantische Analyse des segmentierten Protokolls 

Alle Konzepte der in V, gefundenen Segmente werden durch Lexikonabgleich 
und über Lemmatisierung auf ihre Wortart hin überprüft. Inhaltswörter werden zum 
weiteren Gegenstand der semantischen Analyse. So sind z.B. Nomen eventuell relevante 
Konzepte und können in den zu erzeugenen Operator- Argument Strukturen Argument- 
positionen besetzen. Gleichzeitig wird getest, ob diese potentiellenKonzepte schon durch 
das semantische Netwerk definiert sind. Wenn nicht, so werden entsprechende Objekte 
erzeugt und diese als “leer” markiert. 

(braun verbrannt Dl Oel) 

(beeinträchtigt D2 Kupplung Bremsbänder) 

Ein mögliches Ergebnis dieser Phase: die erste Argumentposition 
ist für die Segment- Marker reserviert 



VII. Vervollständigung der Operator- Argument Strukturen 

Es wird im weiteren nach Wissenselementen gesucht, die die oben gebildeten 
Operator- Argument Strukturen vervollständigen. Dieses geschieht zunächst innerhalb 
desselben Segments, anschließend in den benachbarten Segmenten. 

VIII. Vervollständigung durch Inferenz (knowledge base matching) 

Durch das unter VII. beschriebene Verfahren werden Referenzen, zumal wenn 
sie sich über längere Distanzen erstrecken, nicht erkannt und aufgelöst. Bei sorgfältiger 
Durchführung der Protokollaufnahme sind komplexe syntaktische Konstruktionen al- 
lerdings nicht zu erwarten. Die Vervollständigung der Operator- Argument Strukturen 
geschieht versuchsweise durch die Suche nach kompletten Propositionen, in denen die 
bereits extrahierten Komponenten Vorkommen. Die fehlenden Argumente werden dann 
von diesen Operator- Argument Strukturen, übernommen. 

IX. Zwischengeschaltete Wissensrepräsentation 

Der gesamte Output der Protokollanalyse wird in das zwischengeschaltete Re- 
präsentationssystem integriert. Diese Repräsentationssprache stellt ein propositionales 
Kalkül als Zielsprache für die Protokollanalyse und Textanalyse zur Verfügung. Dekla- 
ratives Wissen wird in einem semantischen Netz bestehend aus strukturierten Objekten 
gespeichert. 

X . Frame- Generierung 

Strukturierte Objekte im semantischen Netz der Zwischenrepräsentationsspra- 
che können in ein Frame- Format übersetzt werden. Grundsätzlich ist es kein Problem, 
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Frame- Generatoren zu schreiben, wobei die Zwischenrepräsentation die Funktion eines 
“blackboards” übernimmt. 

XI. Regel- Generierung 

Die Regelgenerierung stellt einen über Mausoperationen realisierten, interaktiven 
Prozeß dar, bei dem Operator- Argument Strukturen, die in den rechten und linken Teil 
der Regeln eingesetzt werden können, auszuwählen sind. Korrekturen können mithilfe 
eines Struktureditors vorgenommen werden. Die Definition von Regelmengen, sowie 
die Festlegung von Kontrollstrategien bleibt, bisher zumindest, dem Wissensingenieur 
überlassen. 

In unserem Beispiel würden also (braunverbrannt Oel) und (beeinträchtigt Brems- 
bänder Kupplung) zur Regelgenerierung angeboten. Die Entscheidung, was Prämisse 
und was Aktion ist, obliegt dem Benutzer. 

7. Vergleich mit anderen Systemen der automatischen Wissensakqui- 
sition 

Wissensakquisitionssysteme sind bisher nur bedingt bis zur Produktebene ent- 
wickelt worden. Sofern dieser Entwicklungsstand erreicht wurde, so meistens als Teil von 
Expertensystem-Shells. Autonome Wissensakquisitionssysteme, die für verschiedene 
Wissensrepräsentationsformalismen und Expertensystem-Shells zu verwenden sind, ha- 
ben oft nur experimentellen Charakter. 

Es sind zwei Entwicklungsstränge zu beobachten: Wissensakquisitionsysteme, 
die fast ausschließlich auf der Verwendung maschineller Lernverfahren beruhen, und 
Systeme, die auf kognitionswissenschaftliche Ansätze zurückzuführen sind. Beiden Ty- 
pen ist in den meisten Fällen gemeinsam, den Aufbau einer Konzept-Taxonomie für ein 
Problemfeld große Bedeutung beizumessen und diese Aufgabe auch an den Anfang des 
Wissensakquisitionsprozesses zu stellen. 

KRITON wurde in hohem Maße durch KADS stimuliert [5]. KADS ist ein Sys- 
tem, das eine Vielzahl an Funktionen umfasst, wie z.B. Assistenz bei Planungsauf- 
gaben, Protokollanalyse, Dateninterpretation und Konsistenzüberprüfung. Kernstück 
des Systems sind Aufbau und Verwendung von Interpretationsmodellen, die den Wis- 
senSakquisitionsprozess für ein bestimmtes Anwendungsfeld leiten und kontrollieren. Im 
Gegensatz zu KRITON ist KADS jedoch kein integriertes System, sondern hat eher den 
Charakter einer Programmbibliothek. 

ETS [4] ist ein interaktives System für den Aufbau regelbasierter Systeme. Das 
System besteht im wesentlichen aus einer on-line Realisierung des repertory-grid tests 
von Kelly [10]. Für die Regelgenerierung wird zunächst mithilfe faktorenanalytischer 
Methoden ein Implikationsgraph aufgebaut, der die Grundlage für die Bildung einfa- 
cher Regeln darstellt. In neueren Versionen von ETS ist das Experteninterview um 
weitere Verfahren bereichert worden, u.a. durch laddering-Techniken. ROGET [2] 
ist ebenfalls ein System, das eine direkte Interaktion des menschlichen Experten mit 
der Wissensakquisitionskomponente erlaubt. ROGET generiert eine Regelbasis, die 
als Repräsentation der konzeptuellen Struktur eines Problembereiches verstanden wird. 
Eine ROGET-Konsultation wird zur Bewältigung folgender Aufgaben durchgeführt: 

• Definition der Art der Problemlösung 

• Akquisition der konzeptuellen Struktur eines Problembereiches 
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• Analyse der konzeptuellen Struktur 

• Operationalisierung der konzeptuellen Struktur für verschiedene knowledge engi- 
neering Aufgaben. 

BLIP (Berlin Lerning by Induction Program, [13]) ist ein maschinelles Lern- 
verfahren, das im wesentlichen auf den Einsatz von Metawissen beruht. Durch In- 
duktion werden Regeln generiert, die ein bestimmtes Sachgebiet strukturieren. Dabei 
wird zwischen sachgebietsabhängigen und -unabhängigen Wissen unterschieden. We- 
sentlicher Bestandtteil des Systems ist domainunabhängiges Metawissen in Form von 
Metaprädikaten, was das Vorwissen des BLIP ausmacht. 

8. Implementation 

Alle beschriebenen Komponenten KRITONs sind in einer vorläufigen Form in 
Interlisp-D und Loops geschrieben und laufen auf einer Xerox 1108. Das semantische 
Netz als Teil der Ebene der Zwischenrepräsentation ist vollständig in Loops realisiert. 
Die inkrementeile Textanalyse existiert in einer weiteren Fassung in Franz Lisp und 
läuft auf einer VAX 11/750. Eine Implementation der inkrementellen Textanalyse in Le 
Lisp für Apple Macintosh wird angestrebt. 

Protokoll- und Textanalyse machen Gebrauch von einem Funktions wörter- Lexi- 
kon. Für die Protokoll analyse werden wie beschrieben weitere, domainabhängige Lexika 
benötigt. 

Sowohl Text-, als auch Protokollanalyse beinhalten eine Lemmatisierungskompo- 
nente, deren Kernstück eine Flexionsanalyse ist. Die Lemmatisierung ist teils regel-, 
teils lexikonbasiert (die Vorgehensweise ist an Bergmann [3] orientiert). Die Reliabilität 
des Verfahrens liegt bei 90% und ist somit vergleichbar zu anderen Ansätzen. 

9. Fazit und Ausblick 

Wir streben ein integriertes, modulares Werkzeugsystem für die Wissensakqui- 
sition für Expertensysteme an. Auf der einen Seite sollte das System in hohem Maße 
Unterstützung für den Erwerb deklarativen und prozeduralen Wissens geben. Auf der 
anderen Seite sollte es offen für Erweiterungen sein, so daß neue Erwerbsmethoden 
einfach in das System integriert werden können. Ein mittelfristiges Ziel ist die Inte- 
gration maschineller Lernverfahren, insbesondere eine Kombination aus Analogielernen 
und erklärungsbasierter Generalisierung. 

Zum gegenwärtigen Zeitpunkt arbeiten Protokoll- und Textanalyse noch fehler- 
behaftet. Dieser Mangel wird durch die Bereitstellung von Struktureditoren auf der 
Ebene der Wissensbasisgenerierung zu kompensieren versucht. Eine höhere Reliabilität 
der Verfahren wird aber sicherlich durch einen Ausbau der Lexika zu erreichen sein. 

Zusammenfassend kann gesagt werden, daß der in KRITON realisierte Ansatz 
nicht nur geeignet erscheint, hybride Wissensrepräsentationssysteme zu unterstützen; 
durch den Einsatz unterschiedlicher Wissensquellen wird die Akquisition verschiedener 
Wissensformen erreicht und damit eine Vielschichtigkeit in der Akquisition erzielt, die 
durch kaum ein anderes Verfahren erreicht wird. Nach unserer Einschätzung ist insbe- 
sondere die Offenheit für Erweiterungen eine Eigenschaft, die den Einsatz KRITONs in 
umfangreichen industriellen Anwendungsgebieten begünstigen sollte. 
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Von der Wissensakquisition zur 
Phylogenese wissensbasierter Systeme 

Rainer Lutze 

TA TRIUMPH-ADLER AG Nürnberg 



Zusammenfassung : Die bisherige Praxis der Wissensakquisition geht von 
letztlich Trvüuiti v gewählten Wissensarten aus. Eine systematische und 
wirtschaftliche Faktoren berücksichtigende Konstruktion ist damit 
höchstens zufällig zu erreichen; die Methodik des Vorgehens ist überdies 
so nicht lehrbar. Es wird stattdessen eine phasenorientierte 
Konstruktionssystematik für Wissensbasen vorgeschlagen, die aus dem 
a 1 1 gerne i nen i ngen i eurwi ssenschaf 1 1 i chen Vorgehen der Konstrukt i on 
technischer Systeme hervorgeht. 

Abstract : The currently used practise of knowledge aquisition is based 
on a finally intuitive selection of knowledge types. In this way, a 
systematic construction taking account for economic factors can only be 
approached incidently. Moreover, this procedure of knowledge 
acquisition is not teachable. A systematic, phase oriented construction 
method for knowledge bases is presented instead. The method stems from 
the established principles of civil engineering of technical systems. 



1 Einführung 

Die Tätigkeit der Wissensakquisition nimmt nicht nur 
hinsichtlich ihres Aufwandes (Kosten, Zeit) eine zentrale Bedeutung 
bei der Konstruktion wissensbasierter Systeme (WBS) ein (/BMS 86/). Da 
bis auf die Wissensbasis die übrigen Teile eines WBS in vielen 
Fällen aus allgemein verfügbaren Werkzeugsätzen ("Expertensystem 
Shells") mit geringem Aufwand konfiguriert werden können, entscheidet 
vorwiegend die Wissensakquisition über den (wirtschaftlichen) Erfolg des 
WBS. Trotz dieser zentralen Bedeutung der Wissensakquisition sind 
systematische Verfahren zur Wissensakquisition erst ansatzweise entwickelt 
(/Bar 78/, /Boo 86/). In vielen Fällen ist die Wissensakquisition zum 
Selbstzweck der Konstruktion des WBS geworden und ihrer zweckdienlichen 
Funktion im Rahmen des WBS entkleidet. Obwohl von der Aufgabenstellung, 
etwa bei der technischen Diagnose, verwandt, ermangelt die bisherige 
Praxis der Wissensakquisition der in Jahrzehnten ausgearbeiteten 
ingenieurwissenschaftlichen Systematik bei der Konstruktion technischer 
Systeme (vgl. etwa /PaBe 77/). 

Nachdem in Kap. 2 die Funktionen von Expertensystemen präzisiert und in 
Kap. 3 die heute verfügbaren Werkzeuge zur Wissensakquisition näher 
klassifiziert worden sind, werden wir in Kap. 4 kurz die bei der 
Konstruktion technischer Systeme übliche allgemeine ingenieurwissen- 
schaftliche Konstruktionssystematik vorstellen. Auf dieser Grundlage wird 
dann in Kap. 5 eine speziell angepaßte Konstruktionssystematik für Wissens- 
basen zu entwickeln versucht. 
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2 Die Zweckfunktion von Expertensystemen 

Die Fähigkeiten eines Expertensystems in der Herbeiführung 
planmäßiger und zielbewußter Wirkungen bezeichnen wir als 

Zweckfunktion des Expertensystems (nach /Hub 84/, Kap. 5). Ihre 
Realisierung ist Ziel einer Konstruktion eines Expertensystems. 

Die Zweckfunktion ist von den technischen Funktionen des 
Expertensystems abzugrenzen, die die Prinzipien der Realisierung 
des Expertensystems darstellen, mithin die Mittel zur Erreichung des Ziels. 

Die Zweckfunktion kann durch eine Spezifikation beschrieben werden und 
läßt sich allgemein als die Produktion von Expertise charakterisieren. In 
der Spezifikation sind entweder der Inhalt der Expertise festgelegt (etwa: 
die Bestimmung von Ursachen von Defekten aus Symptomen) oder aber die 
Folgewirkungen, die durch die produzierte Expertise herbeiführbar sein 
müssen (etwa: die betriebssichere Steuerung einer technischen Anlage) . 

Qualitätsziele und Leistungsmerkmale können die Zweckfunktion zusätzlich 
näher bestimmen. 

Unter Expertise verstehen wir die Fähigkeit, aufgrund eines methodisch 
strukturierten Fachwissens und situationsadäquaten Vorgehens 

1) situationsbezogene Zielsetzungen zu formulieren, 

2) Problemlagen zu erkennen und zu analysieren, 

3) Maßnahmen zur Behebung von Problemlagen vorzuschlagen. 

Expertise zeichnet sich auch dadurch aus, daß sie interaktiv und auf 
Nachfragen hin durch Erklärungen nachvollziehbar sein muß. Erklärungen 
sind nach ihrer Zeitbezogenheit in Erläuterungen eines (bekannten) 
Istzustands, (qualitative) Begründungen oder (normative) 

Rechtfertigungen eines Istzustands aus einem früheren Zustand sowie in 
die Planung eines zukünftigen Sollzustands zu differenzieren. 

Qualitätsziele für produzierte Erklärungen schliessen typischerweise 
ein: 



a) Relevanz der Erklärung in bezug auf die aktuell 
vorliegende Situation und die ihr innewohnenden 
Wirkungsgefüge 

b) Nachvollziehbarkeit der Erklärung in bezug auf 
Vorkenntnisstand und (physiologische und kognitive) 
Aufnahmefähigkeit des Benutzers 

c) Prägnanz der Erklärung als Ausmaß von Glaubwür- 
digkeit (Es gibt auch "zu" glaubwürdige Erklärun- 
gen, die eben deshalb falsch sind). 
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d) Güte der Erklärung als Ausmaß des in die Erklä- 
rung eingeflossenen anwendbaren Fachwissens. 

Leistunqsmerkmale können Reaktionszeiten des Expertensystems begrenzen, 
in denen die Expertise zu produzieren ist oder Fehlerraten festlegen, in 
denen die produzierte Expertise höchstens von der tatsächlichen Situation 
abweichen oder zu einer falschen Folgewirkung führen darf. 

Eine wissenschaftliche Ausarbeitung solcher Qualititätsziele und 
Leistungsmerkmale insbesondere im Hinblick auf ihre Prüfbarkeit, 
steht aber noch aus. 

3 Verfügbare Werkzeuge zur Wissensakquisition 

Die heute verfügbaren Werkzeuge zur Wissensakquistion lassen sich 
prinzipiell drei Klassen zuordnen, wobei für praktische Systeme 
Mischformen Verwendung finden müssen: 

- Wissenseditoren 

- Wissensstrukturierer und -validierer 

- Wissensinduktoren 

Bei den Wissenseditoren handelt es sich im engeren Sinn um Werkzeuge 
zur Formalisierung von Wissen (/LaSm 85/, /MDW 85/, /SDB 86/) oder 
aber vorwiegend zur Visualisierung (etwa: "SMALLTALK System Browser", 
/Gold 83/), die Akquisition wird meist nicht spezifisch unterstützt. 

Die Wissensinduktoren stellen Hilfsmittel zur Verknüpfung von Symptomen, 
Hypothesen und Ursachen zu Implikationen sowie zur Festlegung spezifischer 
Signifikanzen bereit (/KND 85/,/EsDe 86/). Gelegentlich werden auch 
Diskriminationsnetze erstellt ( /MMRZ 84/). Überwiegend werden die 
Werkzeuge durch die Abstraktion aus geeigneten Beispielen gesteuert. Solche 
"typischen" Beispiele sind aber zumeist nur sehr schwer zu bestimmen. 

Mit Strukturierungs- und Validierungswerkzeugen können Begriffswelten 
gebildet (/Boo 84/), strukturierte Begriffe aus elementarem aufgebaut 
(/ChFu 84/) oder Begriffe in bestehende Taxonomien eingeordnet werden 
( / SchL i 83/). Regeln können (statisch) auf Vollständigkeit und 
Widersprüchlichkeit untersucht werden (/ SSS 82/, /NPLP 85/) oder nach 
gewissen Kriterien umstrukturiert werden (/PoWe 84/). Eine Analyse der 
Regeln muß sich in diesem Fall auf eine dynamische Ausführung, 
Interpretation, stützen, wie sie schon durch die "klassische" 
TEIRESIAS-Komponente von MYCIN (/BuSh 85/) realisiert worden ist. 
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Allen Werkzeugen ist gemeinsam, daß sie vorgegebenes Wissen als solches 
akzeptieren und sich nur durch eine spezifische Art der Aggregierung und 
Vervollständigung dieses Wissens auszeichnen. Soweit es sich um die 
Zweckmäßigkeit von Wissen zum Erreichen der Zweckfunktion des 

wissensbasierten Systems handelt, sind die Werkzeuge nicht systematisch. 

4 Die ingenieurwissenschaftliche Konstruktionssystematik 

Bei der Konstruktion eines technischen Systems, als welches wir hier auch 
ein WBS verstehen möchten, ist zunächst zu prüfen, ob (1) eine 
Neukonstruktion (Anwendung eines neuen Lösungsprinzips bei ggfs, gleicher 
Aufgabenstellung), (2) eine Anpassungskonstruktion (Adaption des 
technischen Systems an eine neue Aufgabenstellung durch neue 
Tei lfunktion(en) unter Beibehaltung des ursprünglichen Lösungsprinzips) 
oder (3) eine Variantenkonstruktion (Adaption durch Variation von 
Parametern unter Beibehaltung von vorhandenen Teilfunktionen und des 

ursprünglichen Lösungsprinzips) sinnvoll und notwendig ist. Der 
Schwerpunkt der industriellen Praxis ( /PaBe 77/ nennen ca. 55%) liegt 
dabei im Bereich der Anpassungskonstruktionen. 

Der eigentliche Konstruktionsprozess vollzieht sich dann in Kombination 

einer Menge von Analyse- und Synthesetätigkeiten nach dem Muster von Fig. 

1 (vgl. /PaBe 77/). 

Übersichtsartig lässt sich der Prozess als Abfolge der Phasen: 

- Klärung der Aufgabenstellung 

- Konzeption ( Bestimmung des "Wesenskerns" der Aufgabe 
durch Abstraktion, Aufstellen von Funktionsstrukturen 
durch Zergliederung der Zweckfunktion in Teilfunktio- 
nen, Suchen nach Lösungsprinzipien, Kombination von 
Lösungsprinzipien zu Varianten, technisch/wirtschaft- 
liche Bewertung der Konzeptvarianten und Auswählen ) 

- Entwurf ( Gestaltung nach technisch/wirtschaftlichen 
Gesichtspunkten, Bewertung von Teillösungen und deren 
Kombination, Integration unterschiedlich bewerteter, 
konkurrierender Teillösungen zu Gesamtlösungen, 
Mängelbehebung und Optimierung der Form der Problem- 
lösung) 



- Ausarbeitung ( Überprüfung der Herstellungsmöglich- 
keiten und Kosten, Einbindung relevanter Vorschriften 
und Normen (etwa: Sicherheit) 



zusammenfassen. 
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in Teilfunktionen 



* 



{verbesserungsbedürft 



♦ 



Technisch / wirtschaftliche „ 
Bewertung der Funktionalität 



(Veränderung 
der Funktion) 



* 



^Pr (positiv) 



r 



Umstrukturierung und 
Optimierung der Form 



♦ 



Technisch / wirtschaftliche 
Bewertung der Form 



(gestaltende Phase) J 



(positiv) 



Dokumentierung 


4l 




Vervollständigung, 
Einarbeitung von Ricritlinien 


* 


Vollständigkeitsprüfung 



♦ 



(positiv) 



FIGUR 1: 

CKeizEOEßGISCSBEKElrEßPtLCElIE CSßlitCJE'EtCeßieSV-'etfarae'SCß 




- 227 - 



Zunächst sind die Anforderungen an ein Produkt zu klären und zu einer 
Gesamtheit der Zweckfunktionen des Produkts zu konfigurieren. Sodann werden 
die Zweckfunktionen hinsichtlich einzelner (technischer) (Teil)funktionen 
zerlegt. Für eine ausgewählte Teilfunktion wird ein Lösungsprinzip zu 
ihrer Realisierung bestimmt und die Teilfunktion anschließend in ihrer 
technischen Ausprägung entworfen. Dieser Entwurf wird in die bisherige 
(technische) Gesamtfunktionalität des technischen Systems integriert und 
mit der angestrebten Zweckfunktionalität verglichen. Ist diese noch nicht 
erreicht, werden weitere, noch fehlende Teilfunktionen identifiziert und 
realisiert. Ist die Zweckfunktionalität erreicht, werden gewisse 
vorzugebende Optimal itätskriterien, zumeist Kosten- oder Sicherheits- 
kriterien, auf den Grad ihrer Erfüllung überprüft. Ist dieser Grad 
unzureichend, wird durch eine Variation der Form der Realisierung einer 
Einzelfunktion eine Verbesserung der Gestaltung herbeizuführen versucht. 



5 Grundlagen einer Konstruktionssystematik 

für Wissensbasen 

Grundlage des Verfahrens ist eine sinngemässe Übertragung des in Kap. 4 
vorgestellten allgemeinen ingenieurwissenschaftlichen Vorgehens im Rahmen 
der in Kap, 2 definierten Zweckfunktion von Expertensystemen. Ein solches 
Vorgehen beschreibt einen Problemlösungsprozeß durch Komposition 
neuartiger Strukturen. Diese Betrachtungsweise ist u.E. angemessener als 
das Paradigma der Programmkonstruktion, das auf einem Problemlosen durch 
Analogiebildung beruht und letztlich in der Kombination individuell 
bekannter algorithmischer Muster (wie: Suchverfahren, Aufzählungs- 
verfahren) resultiert. 

Die Klärung der Aufgabenstellung t die in der Konfiguration der Zweck- 
funktion resultiert, haben wir im Kontext dieser Arbeit unbetrachtet 
belassen. Die Phasen 5.1 bis 5.3 decken die funktionale Phase der 
ingenieurwissenschaftlichen Konstruktionssystematik aus Kap. 4 ab, mit dem 
Schwerpunkt auf der Festlegung der Begriffsfunktion in Kap. 5.2. Die 
gestaltende Phase der allgemeinen Systematik aus Kap. 4 findet sich in der 
Ausarbeitung der Begriffsformalisierung in Kap. 5.4 wieder, allerdings be- 
sitzt auch die in Kap. 5.3 beschriebene Festlegung der Begriffsgestalt 
entsprechende gestalterische Anteile. Im Gegensatz zu der Systematik aus 
Kap. 4 ermangelt unser Phasenmodell noch der eindeutigen Zwischen- 
bewertungen, die den Charakter von Meilensteinen haben und einen 
Phasenwechsel einleiten. 



Ausgangspunkt einer Konstruktion ist ein in der realen Welt oder unserer 
Vorstellung (kurz: der Anwendungswelt) existierendes System, das durch 
seine (strukturierte) Substanz, die Gegenstände , die Konfiguration der 
Gegenstände in (beobachtbaren) Zuständen und die (beobachtbaren) 
Transformationen von Zuständen gekennzeichnet ist. Die atomaren 
Bestandteile von Zuständen sind Sachverhalte , die wahrheitsfähige 
Aussagen über Gegenstände (kurz: Gegenstandsaussagen) darstellen. 
Gegenstände, Sachverhalte, Zustände und (Zustands)transformationen (kurz: 
Konzepte) können durch Merkmale beschrieben und durch Begriffe ausge- 
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drückt werden. 



/Doy 85/ stellt die Konstruktion der Wissensbasis als Kern der 
Konstruktionstätigkeit für ein Expertensystem heraus, da sie (im 
softwaretechnologi sehen Sinn) eine interpretierbare Spezifikation der 
Aufgabenstellung bereitstellt., und damit eine Realisierung des Rapid 
Prototyping darstellt. Uber die besonderen Vorzüge des 
konzeptorientierten Vorgehens vgl. /Bor 85/ (od. /Boo 86/ wegen 
softwaretechnischer Aspekte). 



5.1 Festlegung der Begriffsmengen 

Es werden alle Begriffe erfaßt, die a) Ziele b) Probleme c) Maßnahmen 
zum Erreichen der Ziele bzw. zur Behebung von Problemen beschreiben, die 
durch das Expertensystem zu behandeln sind. Dabei ist insbesondere zu 
berücksichtigen, inwieweit die unter a) bis c) beschriebenen Konzepte 
nicht nur als Teil von Erläuterungen von "IST"-Zuständen, sondern als 
Teil von früheren Zuständen oder geplanten Zuständen oder im Kontext von 
Zustands transformationen erklärungsbedürftig auf treten. 

Begleitend kann die obligatorische Prüfung vollzogen werden, ob sich die 
Anwendungswelt überhaupt für die Konstruktion eines Expertensystems 
eignet (vgl. /Pre 85/ für eine Kriterienliste). 



5.2 Festlegung der Begriffsinhalte (Begriffsfunktion) 

Die Festlegung der Begriffsinhalte gliedert sich in die Bestimmung der 
eigentlichen Bedeutung (5.2.1), die sich aus der formalen Repräsentation 
eines Begriffs ergibt, sowie der Abgrenzung seines Begriffsumfeldes durch 
formal repräsentierte Querbezüge zu anderen Begriffen (5.2.2). 

Wir gehen dabei zunächst von einer maximal möglichen Differenzierung 
zwischen Begriffen aus, da sich aus dem Umfang der Differenzierung die 
Funktion eines Begriffs bestimmt, den dieser in einem Expertensystem 
erfüllen kann ("Analyse der möglichen Begriffsfunktion"). Anschließend 
wird durch eine technisch/wirtschaftliche Bewertung beurteilt, in welchem 
Umfang eine solche Differenzierung zum Erreichen der Zweckfunktion 
tatsächlich notwendig und ökonomisch sinnvoll ist. Im Anschluß an die 
damit getroffene Festlegung der Begriffsfunktion können unterschiedlich 
differenzierte Begriffe in den Grenzen der zur Verfügung stehenden 
Wissensrepräsentation dann durchaus gleichartig formal repräsentiert 
werden ("Synthese der tatsächlichen Begriffsfunktion 11 ). 

5.2.1 Die Begriffsbedeutung (Denotation) 

Es wird die "Modellierungstiefe" eines in 5.1 erfaßten Begriffs abhängig 
davon festgelegt, ob er einerseits a) extensional, nur durch das Bestehen 
einer wahrheitsfähigen Aussage, b) durch seine Struktur, c) durch seine 
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Struktur und eine ihm innewohnende Intention oder d) durch seine 
Struktur, seine Intention und eine mit ihm verbundene Modalität 
ausgedrückt werden soll. Andererseits ist die Art des Wissens zu 
berücksichtigen, ob etwas Statisches, seiend Faktisches beschrieben 
werden soll oder eine Schlußfolgerung , die (als Funktion über einem 
Zustand) zusätzliches Wissen über diesen Zustand ableitet, oder aber eine 
Zustandstransformation , eine Zustände verändernde Operation. Figur 2 
gibt die möglichen Kombinationen an. 

In der am wenigsten umfänglichen Modell ierungsstufe werden Wissensarten 
nur durch Prädizierung benannt: Sachverhalte, Funktionen, Operationen. 
Auch Objekte sind nur Namen, "Stel lvertreter" für (unstrukturierte) Gegen- 
stände. 

Haben die Konzepte eine Struktur, wird faktisches Wissen durch Objekte , 
das Bilden von Schlußfolgerungen durch Regeln und werden 
Zustandstransformationen durch Prozesse beschrieben. Dabei kommt es 
weniger auf die exakte Definition etwa eines Objekts in einem speziellen 
Repräsentationsmechanismus an, als vielmehr darauf, daß es überhaupt 
unterschiedliche Konzepte gibt, um die logische Verknüpfung (Disjunktion, 
Konjunktion, Negation) von Sachverhalten in einer Regel von einer 
zeitlichen Verknüpfung (Simultanität , Überlappung, Sequenz) in einem 
Prozeß, und diese wiederum von der zeitlich/logischen Präsenz von 
Gegenstandsaussagen (in einem Objekt) unterscheiden zu können. 

Faktisches, das nicht nur durch seine Struktur, sondern auch durch eine 
Intention bestimmt wird, finden wir vor allem als "intentionales 
Zeichenobjekt" bzw. Designat im Prozess der Semiose (/Morr 38/). Regeln, 
bei denen ihre intendierte Verwendungsmöglichkeit mit beschrieben ist, 
bezeichnen wir als Schlußprinzipien . Zeitliche Transformationen, die zur 
Erreichung einer bestimmten Intention optional eingesetzt werden können 
(und damit notwendigerweise durch ein belebtes Wesen ausgelöst werden 
müssen), sind Handlungen . 

Wird eine Modalität (sollen, können, dürfen, müssen) der Strukturierung 
eines Schlußprinzips oder einer Handlung beschrieben, erhalten wir Gebote 
oder Handlungsanweisungen . 

5.2.2 Der Begriffskontext (Konnotation) 

In dieser Phase wird bestimmt, welche Ober-, Unter-, 
Synonymbegriffsbeziehungen oder Mittel /Zweck- bzw. Instrument/Ziel - 
Beziehungen zum Erreichen der Zweckfunktion des Expertensystems notwendig 
sind und die entsprechenden Begriffe werden erfaßt und definiert. 
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5.2.3 Technisch/wirtschaftliche Bewertung 

Die Bewertung der bisher definierten Begriffe muß (1) vom Wert des 
Begriffsinhalts (zum Erreichen der Zweckfunktion) und (2) vom ökonomischen 
Aufwand für die angestrebte Begriffsverwendung ausgehen. Für die 

Wertanalyse ist von einer Kosten- / Nutzenanalyse auszugehen, deren 
Nutzendefinition im Kontext der Qualitätsziele und Leistungsmerkmale des 
Expertensystems spezifisch festzulegen ist. 

5.2. 3.1 Bewertung von Begriffsinhalten 

Die Kosten CM(k,s), die für die Modellierung eines Konzepts k in einem 
Zustand s entstehen, lassen sich in Kern als Summe: 



CM(k,s) 



n 



m 



F(n,p) + > M(hi) + > CM(kj) 



P 

+ > CM( lu) 



i=l.& 
hi $ s 



KJ $ S 



U=1 ,& 

lu f s 



o der Kosten CM(hi) für die Strukturbestand- 
teile hi von k, l<i<n, die selbst 
wieder weitere, noch nichT modellierte Konzepte 
sind, 



o der Kosten CM(kj) für diejenigen weiteren 

Konzepte kj, l<j<m, die zur Modellierung der 
mit dem Konzept 1c verbundenen Intention not- 
wendig sind, 

o der Kosten CM(lu) der weiteren Konzepte lu, 

l<u<p, die in mit dem Konzept k verbundenen 
SaclTverhalte auftreten, 



o der Kosten F(n,m,p) für die Modellierung von k 
selbst (praktisch: Fixkosten) 



abschätzen. (Die Kosten der Modellierung eines Konzepts bestimmen sich 
also aus den Kosten der zu seiner Modellierung benötigten weiteren 
Konzepte). Die Kosten der Modellierung eines Konzepts werden nur einmal 
berechnet. Kosten sind also dann besonders günstig, wenn eine 
"geschlossene" Begriffswelt mit minimaler Begriffsmenge vorliegt. 



Der Nutzen eines Begriffsinhalts kann nun spezifisch durch Bewertung der 
in Kap. 2 definierten Qualitätsziele a) - d) in Abhängigkeit von der 
antizipierten Benutzergruppe des Expertenstems festgelegt werden. Es 
erscheint einsichtig, daß insbesondere die Nachvollziehbarkeit von 
Erklärungen durch die spezifische Ausprägung der Wissensarten 
"Schlußfolgerung" und "Handlung" beeinflußt wird. 
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5.2. 3.2 Bewertung der Begriffsverwendung 

Zweck der vorgeschlagenen Konzeptdifferenzierung ist eine Begrenzung und 
Abschätzung der möglichen Seiteneffekte von Konzepten und damit der 
Implementierungskomplexität bzw. Festlegung der Anforderungsdefinition an 
ein Expertensystem. So ist die Verwaltung von Objekten mit ihren lokalen 
Seiteneffekten auf den internen Zustand ein technisch handbares Problem, zu 
dem objektorientierte Sprachen wie SMALLTALK auch Lösungen bereithalten. 
Umfangreiche PLanungen, wie sie für Prozesse/ Handlungen notwendig sind, 
werfen aber nicht nur ein schwerwiegendes Effizienzproblem auf, sondern 
stellen auch spezielle Anforderungen an die Objektrepräsentation, um 
partielle Objektbeschreibungen und Konsistenzbedingungen mit ihnen 
repräsentieren zu können (/Stef 81/). Umfangreiche Mengen von Regeln oder 
Schlußprinzipien erforderen i.A. Techniken zur inkrementellen 
Überprüfung von Regelbasen, wie sie durch den RETE-Algorithmus angeboten 
und in Systemen wie 0PS5 realisiert sind. Die Repräsentation von 
Modalität ermangelt noch ausgearbeiteter wissenschaftlicher Grundlagen, so 
daß für solche Systeme substantielle Forschungsaufwendungen, in ihren 
produktbezogenen Aspekten ungewisse und sicher frühestens auf längere 
Sicht gültige Erfolgsaussichten zu berücksichtigen sind. 



5.3 Festlegung des Begriffsumfangs (Begriffsgestalt) 

Ziel der Phase ist eine Optimierung der Gestalt des zu formal isierenden 
Wissens durch Minimierung der Kosten der für die Erfüllung der 
Zweckfunktion des Expertensystems zusätzlich notwendigen 
technisch/wissenschaftlichen Verfahren (vgl. hierzu auch /HWL 83/ , Kap. 4, 
für eine Übersicht verfügbarer Verfahren). 

Abhängig von den Möglichkeiten des verwendeten Wissensrepräsentations- 
formalismus muß entschieden werden, welche Begriffsinhalte explizit, 
durch Strukturen, und welche implizit, durch zu interpretierende 
Rechenvorschriften (d.h. Regeln und Handlungen), niedergelegt werden 
sollen. Die explizite Repräsentation hat den Vorteil, effizient zu sein, 
insofern als die Berechnungen, die zu dem Begriffsinhalt führen, vor der 
Nutzungszeit des Expertensystems' liegen. Der derart berechnete 
Begriffsinhalt wird durch die expliziten Strukturen tabelliert und kann 
effizient zugegriffen werden. 

Diese Vorgehensweise bietet sich üblicherweise für die taxonomische 
Klassifikation von Ober-/Unterbegriffen (vgl. Kap. 5.4.2. 1) bzw. die 
Klassifikation von Konzepten in Exemplare/Prototypen/Klassen anderer 
Konzepte (vgl. Kap. 5. 4. 1.4) an. 
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Die implizite Repräsentation von Begriffsinhalten hat den Preis, zur 
Nutzungszeit des Expertensystems durch die dann (erst) vorgenommene 
Berechnung des Begriffsinhalts (zeit) aufwendig zu sein. Dafür bietet sie 
den Vorteil, daß 1) nur absolut notwendige Berechnungen nachgefragter 
Konzepte ausgeführt werden und 2) durch den nachvollziehbaren 
Berechnungsweg der Begriffsinhalt selbst erklärungsfähig ist. Ist etwa 
die taxonomische Klassifikation von Objekten durch Regeln und Handlungen 
definiert, die die Einordnung von Objekten in das Begriffsgerüst beschrei- 
ben, so ist nicht nur erklärbar, daß ein Begriff etwa Unterbegriff eines 
anderen ist, sondern auch warum dies so ist. 

Die Bedeutung solcher impliziten Repräsentationen insbesondere für 
"qualitatives Reasoning" wird von /Stee 86/ unterstrichen und auch von 
(/NSM 85/) in ihrem "explainable-expert-system (EES)" Ansatz in ihrer 
praktischen Relevanz hervorgehoben. Dabei gilt insbesondere, daß auch 
Regeln das Resultat von Bedeutunqsbi ldungsprozessen sein können und in 
ihrer Entstehungsgeschichte transparent bleiben müssen. 

Explizite oder implizite Darstellung von Begriffsinhalten beeinflußt also 
insbesondere die Leistungsmerkmale und Erklärungsgüte des Experten- 
systems . 

Eine weitere Gestaltüngsdimension ist das Ausmaß der automatisch zu 
verwaltenden Veränderungen an Konzepten und deren Verwendung 
(Entwicklungsgeschichte), eine Verwaltung, die notwendig ist, um adäquate 
Begründungen und Rechtfertigungen generieren zu können. Dieser Faktor 
kann also speziell die Relevanz von Erklärungen beeinflussen. 

Auch die Gestaltung von Unvollständigkeit und Vagheit von Konzepten hat 
nun zu erfolgen. Unvollständigkeit wird typischerweise durch 
Widerruf 1 ichkeit und diese durch Differenzierung von Gegenstandssausagen in 
unwiderrufliche Fakten und widerrufliche Vermutungen, deren Gültigkeit 
sich auf die Abwesenheit weiterer Sachverhalte stützt, modelliert. Zur 
Modellierung von Vagheit kann das Ausmaß der Bindungsstärke einzelner 
Strukturbestandteile eines strukturell beschriebenen Konzepts herangezogen 
werden: als "Maß der Charakterizität" von Komponenten für ein Objekt, 
als "Evidenz" der Konklusion einer Regel, als "Gewicht" der Prämissen von 
Regeln, Handlungen und Prozessen. Unvollständigkeit und Vagheit finden 
also ihren Ausdruck in der Prägnanz von Erklärungen des Expertensystems. 



5.4 Ausarbeitung der Begriffsformalisierung 

Ziel der Phase ist die Sicherstellung der Konsistenz eines formal zu 
repräsentierenden Konzepts in sich und die Integrität einzelner Konzepte 
untereinander. 
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5.4.1 Konsistenzbegingungen 

Konsistenzbedingungen auf Konzepten können in solche speziellen 
Bedingungen unterschieden werden, die formal für ein Konzept 
repräsenf ierbar sind, und allgemeine in Bedingungen, die pragmatisch die 
Konsistenz eines Konzepts an sich betreffen und auf die in 5. 4. 1.1 bis 
5. 4. 1.4 hingewiesen wird. 

Spezielle Konsistenzbedingungen beschreiben Kombinationen zulässiger 
Merkmal ausprägungen von Konzepten und können durch die Technik der 
"constraint propagation" automatisch verwaltet werden. So wird etwa die 
Feststellung einer Komponente eines "Kabels" als "Eingang" die 
Festlegung einer jeweils zugeordneten anderen Komponente als "Ausgang" 
bedingen. 

5.4.1. 1 Konzeptlinearität 

Kein Konzept darf sich selbst als Strukturbestandteil besitzen, wohl aber 
eine Veral lgemeinerung, die das Konzept selbst als eine (unter anderen) 
Alternativen einschl iesst . 

5.4.1. 2 Notwendigkeit und Systematik von Komponenten 

Es ist sicherzustellen, daß die Strukturbestandteile eines Konzepts nur 
notwendige (im Gegensatz zu zufälligen) und systematische (im Gegensatz 
zu nicht zweckunmittelbaren) Merkmalen enthalten. Alle anderen Merkmale 
sind, soweit sie nicht neben der Strukturierung mit weiteren epistemischen 
Primitiven der verwendeten Wissensrepäsentation formalisierbar sind (wie 
Generalisierung (vgl. Kap. 5. 4. 2.1)), durch Sachverhalte , die mit dem 
Konzept zu bilden sind, zu beschreiben. Ein "Antriebsaggregat" ist etwa 
eine systematische Komponente eines "Kraftfahrzeugs", das Merkmal, "in der 
Sonne zu glänzen", ein zufälliger Sachverhalt des Konzepts "Kraftfahrzeug". 

(Es ist wesentlich (/Bor 85/), über die Konzeption der objektorientierten 
Programmierung hinauszugehen, die beliebige, aber damit letzlich 
"bedeutungslose" Aggregafionen zu Objekten zuläßt. Dies wird durch die 
Beschränkung auf abgegrenzte Konzeptarten, die nur aus wohldefinierten 
epistemischen Primitiven (wie Strukturierung, General isierung, 
Exemplar/Klassenbeziehung, ...) aufgebaut und damit erklärungfähig 
sind, gerade erreicht. ) 

5.4.1. 3 (Fügungs)Homogenität von Komponenten 

Die Art der Fügung, die die Strukturbestandteile eines Konzepts zu einem 
Ganzen aggregiert, muß für diese Konzeptart entweder in der Wissensbasis 
gleichmäßig sein, oder, wenn nicht, explizit (z.B. durch Sachverhalte) 
beschrieben sein. 
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Fügung kann hierbei etwa die stoffliche Fügung chemischer Elemente zu 
einer Verbindung, eine bestimmte lösbare Verbindung von Maschinenteilen 
oder die Assoziation wesentlicher Aspekte zu einem "abstrakten" Begriff 
sein. Die Fügungshomogenität ist verletzt, wenn etwa sowohl Hersteller 
(abstrakter Aspekt eines "Kraftfahrzeugs" als "Produkt") wie Motor 
(physikalisches Teil) gleichzeitig Komponente eines "Kraftfahrzeugs" wären. 

5.4.1. 4 Kongruenz von Konzept und Konzeptaussagen 



Konzepte müssen dahingehend unterschieden werden, ob sie eine mögliche 
Klasse von Gegenständen, Schlußfolgerungen oder 
(Zustands)Transformationen beschreiben, ein Beispiel einer solchen 
Klasse: einen Prototyp beschreiben oder ein einzelnes Exemplar , ein 
Individuum, aus einer solchen Klasse. Klassen beschreiben mögliche 
Individuen und sind in ihrer Existenz unabhängig von der Existenz von 
Exemplaren zu sehen. 



Abhängig davon können einer Klasse nur solche Sachverhalte zugeordnet 
werden, die ohne zeitliche Begrenzung und für alle Protoypen und Exemplare 
der Klasse gelten, nämlich Dispositionen . Mit einem Exemplar kann nur ein 
solcher Sachverhalt gebildet werden, der nur zu einem bestimmten Zeitpunkt 
in der Lebensdauer des Exemplars gültig ist, i.e. ein Ereignis . Für 
Prototypen können allgemeine Sachverhalte gebildet werden, die eine 
bestimmte Zeitdauer gelten. (Eine Veränderung eines Objekts kann also die 
(automatische) Invalidierung oder Wiederherstellung eines Sachverhalts nach 
sich ziehen). 

5.4.2 Integritätsbedingungen 

Die Überwachung von Integritätsbedingungen fällt in die "praktisch" 
durch Werkzeuge automatisierbaren Tätigkeiten während der Konstruktion 
von Wissensbasen. Speziell Phasen wie 5. 4. 2. 2 werden etwa in KL-ONE 
(/SchiLe 83/) schon automatisch realisiert. Es ist allerdings auch zu 
konstatieren, daß nichttriviale Wissensrepräsentationen hier prinzipielle 
Probleme hinsichtlich Berechenbarkeit und Effienz aufwerfen (/BrLe 84/). 

5.4.2. 1 Konzepthierarchie 

Die Existenz einer Relation, die die Generalisierung zwischen Konzepten 
beschreibt, ist eine unabdingbare Voraussetzung für den gegenseitigen 
Vergleich von Konzepten (und steuert typischerweise die Vererbung zwischen 
Konzepten). ( PROLOG scheidet damit als Wissensrepräsentation aus! ) Für 
nicht extensional zu repräsentierende Konzepte sind jedoch weiterreichende 
Forderungen zu stellen. Nur Sachverhalte können also hinsichtlich ihrer 
Generalisierung unvollständig beschrieben sein. 

5.4.2. 1.1 Azyklizität 

Die Generalisierungsrelation ist azyklisch und vollständig , 
definiert jeweils partielle Ordnungsrelationen auf den unterschiedlichen 
verfügbaren, strukturell beschriebenen Konzeptarten (Objekten, Regeln, 
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Handlungen, ...) 

5.4.2. 1.2 Spezifischste Verallgemeinerungen 

Auf den Ordnungsrelationen ist jeweils die Operation der spezifischsten 
Verallgemeinerung zweier Konzepte zu definieren. Mit dieser Operation hat 
die geordnete Menge der Konzepte (einer Konzeptart) jeweils einen 
Supremumhalbverband zu bilden, d.h. die "spezifischste Verallgemeinerung" 
zweier Konzepte der gleichen Art ist eindeutig bestimmt. 

Sodann ist für die Komponenten eines Konzepts und die mit ihm gebildeten 
Sachverhalte zu prüfen, ob sie für das Konzept spezifisch sind oder auch 
Komponenten/Sachverhalte einer Verallgemeinerung sein könnten? In 
letzterem Fall sind solche Komponenten für das allgemeinste mögliche 
Konzept zu formalisieren und aus dem ursprünglichen Konzept zu entfernen. 
(Sie können dann durch Definition geeigneter Vererbungsstrukturen in dem 
ursprüngl ichen Konzept benutzt werden.) 

So ist etwa der "Hersteller" spezifische Komponente eines "Produkts", 
dessen Spezialisierung (unter anderen) ein "kraftfahrzeug" ist. Der 
"Hersteller" ist deshalb vom "Produkt" auf das "Kraftfahrzeug" als 
Komponente zu vererben. Spezifische Komponente des "Kraftfahrzeugs" ist 
etwa das Antriebsaggregat . 

5.4.2.2 Typizität von Konzepten 

Konzepte, die in 5. 4. 1.4 als Klasse, Prototyp und Exemplar klassifiziert 
worden sind, sind auf die Zuordnung von Exemplaren zu Prototypen oder 
Klassen bzw. Prototypen zu Klassen zu überprüfen. Eine Klasse hat den 
“Typ" eines zugeordneten Exemplars oder Prototyps zu repräsentieren. 
Ausgangspunkt sollte eine schwache Typisierung sein, die zuläßt, daß 
die Merkmalsausprägung eines Exemplars Exemplar oder Exemplar einer 
Verfeinerung des das Merkmal (in der zugehörigen Klasse) beschreibenden 
Konzepts ist. So muß etwa an allen Stellen, wo ein "Kraftfahrzeug" als 
mögliche Komponente einer Klasse formuliert ist, für ein Exemplar oder 
Prototyp der Klasse auch ein Exemplar eines "Personenkraftfahrzeug" zu- 
lässig sein, wenn "Personenkraftfahrzeug" eine Spezial izierung von "Kraft- 
fahrzeug" in dem Begrifssgerüst der Wissensreräsentation ist. 

Es gilt, daß die Nichtübereinstimmung zwischen Exemplar/Klasse durch 
Ausschluß der Vererbung bestimmter Merkmale bzw. Einschränkung/Ausdehnung 
bestimmter Wertemengen oder Konsistenzbedingungen exakt zu formalisieren 
ist. Zudem sollte eine solche Nichtübereinstimmung nur in "nicht 
wesentlichen" Merkmalen zulässig sein, also nicht etwa in einer 
unterschiedlichen Strukturierung. 

5. 4. 2.3 Vererbungspolymorphie 

Im Laufe des Vorgehens sind zwei unterschiedliche Arten der Vererbung 
eingeführt worden, (1) die Vererbung aufgrund der Generalisierung von 
Konzepten (in 5.4.2. 1) und (2) die Vererbung zwischen Klassen/Prototypen 
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und Exemplaren (in 5. 4. 2. 2). So kann ein Exemplar oder ein Prototyp zum 
einen definitionsgemäß Merkmale seiner zugehörigen Klasse (etwa: die 
Fähigkeit des Lebendgebärens für Säugetiere) ererben, zum anderen können 
Exemplare "typische" Merkmale auf die zugehörige Klasse weiterreichen 
(etwa: die Fähigkeit des Fliegens für Vögel). 



Abschliessend ist dieses Vorgehen anhand seiner summarischen Auswirkungen 
hinsichtlich pragmatischer Sinnhaltigkeit und effizienzmäßiger Auswirkungen 
auf eine explizite / implizte Repräsentation (vgl. Kap. 5.3) der Vererbung 
hin zu untersuchen. 



Geeignete Vererbungsverfahren sind auszuarbeiten und die notwendigen 
Ressourcen für ein Konzept zu definieren, die die von dem Konzept 
benötigten Dienstleistungen realisieren (etwa: datengesteuerte 
Veränderung des Konzepts vor und nach einem Zugriff). Die 
Konstruktionstätigkeit geht an dieser Stelle in Softwarekonstruktion 
über, für deren Details wir auf /Boo 86/, Kap II, für eine Übersicht 
verweisen. 



5.4.3 Merkmalsdefinitheit 



Ein formal zu repräsentierendes Konzept ist durch die Summe aller 
Merkmale, die es in der formalen Repräsentation besitzt, eindeutig 
identifiziert. Nach Abschluß der Konsistenz- und Integritätsprüfungen 
weiterhin merkmalsgleiche Konzepte sind identisch und damit 
zusammenzufassen. 



6 Schlußfolgerungen 

Die vorgestellte Vorgehensmethodik kann nur als erster Schritt auf dem Wege 
zu einer ausgereiften Konstruktionssystematik für Wissensbasen angesehen 
werden. Sie wird durch neue Entwicklungen auf dem Gebiet der 
Wissensrepräsentation ständig anpassungsbedürftig und insbesondere durch 
verfeinerte Verfahren der technisch/wirtschaftlichen Bewertung 
ergänzungsbedürftig bleiben. Den letztgenannten Verfahren wird 
insbesondere zur Bewertung kommerziell verfügbarer Wissensbasen steigende 
Bedeutung für Anpassungskonstruktionen zukommen. In der Möglichkeit von 
Anpassungskonstruktionen liegt auch gerade ein langfristiger ökonomischer 
Vorteil der durch Wissensbasen im Resultat symbolisierten 
konzeptorientierten Entwurfstechnologie (/Lu 86/). 

Seine Ausreifung kann die vorgestellte Vorgehensweise aber nur dadurch 
finden, daß die anfänglich intuitive Art der bisherigen 
Wissensakquisition so schnell wie möglich überwunden wird. 
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Der graphische Wissenseditor ZOO: 
ein Metasystem zur Visualisierung 
und Manipulation von Wissensbasen 

Dr. Wolf-Fritz Riekert 

Forschungsgruppe INFORM, Universität Stuttgart 



Zusammenfassung: Wissensbasiert aufgebaute Anwendungssysteme ermöglichen 
den Einsatz von sogenannten Metasystemen, mit welchen die verfügbaren Konzepte benut- 
zergerecht dargestellt und verändert werden können. Der Wissenseditor ZOO 1 ist ein Me- 
tasystem zur Visualisierung und Manipulation von Wissensbasen in einer zweidimensionalen 
graphischen Darstellung. Objektorientiert aufgebaute Wissensbasen werden in Form eines 
Netzes von Bildschirmobjekten dargestellt. In dieser Darstellungsform kann ein Anwen- 
dungsspezialist die Konzepte eines von ihm benutzten wissensbasierten Softwaresystems un- 
tersuchen. Darüber hinaus wird er bei der Modellierung von Fachwissen unterstützt. 
Mittels direkter Manipulation von Bildschirmobjekten können neue Wissensbasen aufgebaut 
und die vorhandenen modifiziert werden. Die vorgenommenen Änderungen wirken sich auf 
das Verhalten des Anwendungssystems unmittelbar aus. 



1. Wissensbasierte Metasysteme 

Computer werden zunehmend in Problembereichen eingesetzt, die sich 
schwer strukturieren lassen, beispielsweise in der Bürowelt, bei Planungsaufgaben, 
bei Designproblemen, in der Diagnose oder in der Konstruktion. Zwei Merkmale 
sind allen diesen Arbeitsbereichen gemeinsam: Es fehlt die formale Beschreibung 

des Problemgebiets, und es gibt keine wohldefinierten Handlungsziele. Daher ist 
es schwierig oder gar unmöglich, eindeutig definierte Lösungsmethoden für die 
Problemstellungen aus diesen Arbeitsgebieten zu finden. 



^ie Entwicklung des Systems ZOO wurde freundlicherweise von der Firma Triumph-Adler AG, 
Nürnberg im Rahmen eines Kooperationsvertrags finanziert und wurde in der Forschungsgruppe 
INFORM an der Universität Stuttgart durchgeführt. Die Forschungsgruppe INFORM wird inner- 
halb des Verbundprojekts WISDOM vom Bundesminister für Forschung und Technologie (BMFT) 
sowie von den Industriepartnern des WISDOM-Projekts gefördert. 




242 



Bei der Anwendung von Computersoftware in diesen Gebieten hat der 
Benutzer des Systems deshalb große Schwierigkeiten zu überwinden: 

• Da die Zielkriterien und Lösungswege nicht von vornherein eindeutig sind, fällt 
es einem Menschen schwer, die vom Computer gefundenen Lösungen zu akzep- 
tieren. Der Benutzer weiß nicht, welches konzeptuelle Modell einer Computer- 
entscheidung zugrundeliegt. Die Dokumentation des Programmes hilft häufig 
nicht weiter, da dort meist nur die Softwarestruktur des Programmes, aber 
nicht die zugrundeliegenden Konzepte des Anwendungsgebiets beschrieben sind. 
Außerdem gibt es eine Reihe von Phänomenen dynamischer Natur, die nicht 
alle in einer statischen Beschreibung vorweggenommen werden können. Oft 
liegt die einzige Erklärung für das Verhalten eines Softwaresystems im Pro- 
grammcode und den aktuellen Werten der Daten. 

• Da das Anwendungsgebiet nicht ausreichend formalisiert ist, ist die erstellte 
Software prinzipiell unvollständig. Der Systemersteller kann nur Heuristiken 
folgen, die sich erst noch in der Praxis bewähren müssen. Beim Einsatz des 
Systems werden dann dem Benutzer neue Kriterien offenbar, die eine Modifika- 
tion der Software erfordern, die wiederum durch den Softwarespezialisten vorge- 
nommen werden muß. Dadurch entsteht ein fortwährendes Kommunikations- 
problem zwischen dem Benutzer und dem Programmierer der Software. Für 
viele praktische Anwendungen dauert ein solcher Revisionszyklus zu lange. Da- 
her haben viele Benutzer den Wunsch, fällige Änderungen selbst vornehmen zu 
können. 

Bei der Beurteilung von komplexen Softwaresystemen gewinnen also zwei 
Kriterien wachsende Bedeutung: die Durchschaubarkeit und die Adaptierbarkeit 
des Systems durch seinen Benutzer. Diese Kriterien sind jedoch beim Einsatz von 
herkömmlich aufgebauten Systemen in schwer strukturierbaren Problemräumen 
nicht erfüllt. Benötigt werden daher neue Softwarekonzepte und neue Systemkom- 
ponenten, die besser auf die Sichtweise der Benutzer abgestimmt sind als die her- 
kömmlichen Programmkonstrukte und Programmierwerkzeuge. 

Einen Weg hin zu diesem Ziel eröffnen wissensbasierte Systeme, also 
Systeme,’ deren Verhalten sich aus einer Wissensbasis ableitet. Technisch gesehen 
ist das Wissen in einer Wissensbasis eine Ansammlung von Softwareobjekten. Es 
ist daher möglich, für wissensbasierte Systeme Komponenten zu entwerfen, die die- 
se Softwareobjekte selbst zum Gegenstand haben. Solche Systemkomponenten ste- 
hen über dem eigentlichen Anwendungssystem und werden als Metasysteme 2 be- 



2 

Die ersten wissensbasierten Metasysteme wurden in der Universität Stanford entwickelt: Typische 

Beispiele sind die Systeme EMYCIN, Teiresias und Meta-DENDRAL, bei denen es sich um Meta- 
komponenten zu den bekannten Expertensystemen MYCIN und DENDRAL handelt [3]. 
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Abbildung 1: Der Wissenseditor ZOO 



zeichnet. Metasysteme haben Zugriff auf das Wissen, welches vom Anwendungssy- 
stem genutzt wird, und können so das Verhalten des Anwendungssystems erklären 
und steuern. 

Der hier vorgestellte Wissenseditor ZOO (Abbildung 1) ist ein Metasy- 
stem, das zweierlei Zwecken dient: es ist zugleich ein Instrument zur Inspektion 

von Wissensbasen in einer zweidimensionalen graphischen Darstellung und ein 
Werkzeug zur Bearbeitung von Wissensbasen mit Hilfe direkter Manipulation von 
Bildschirmobjekten. Das System ZOO erscheint für seinen Benutzer ähnlich ein- 
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fach wie ein System zur Darstellung und Konstruktion von Bürographiken. Die 
Funktionalität des Systems ist freilich viel größer als die eines Bürographik- 
Systems. In jedem dargestellten graphischen Objekt wird ein Ausschnitt aus der 
systeminternen Wissensbasis für den Benutzer sichtbar. Mit jedem vom Benutzer 
neu erzeugten graphischen Objekt wird auch ein Objekt der Wissensbasis angelegt. 

Weil gleichzeitig mit der Graphik eine Wissensbasis entsteht, sind die 
Vorgänge des Designs und der Implementation und der Dokumentation wissensba- 
sierter Systeme parallelisiert. Die erstellten graphischen Spezifikationen stellen zu- 
gleich unmittelbar ablauffähige Software dar. Das System ZOO unterstützt so das 
Rapid Prototyping wissensbasierter Systeme. 

2. Externe Darstellung von Wissen 

In unseren Softwaresystemen benutzen wir ObjTalk [14], eine objektori- 
entierte Sprache, zur Repräsentation von Wissen. ObjTalk vereinigt das Prinzip 
des Message-Passing [9] und die Frametechnik [12] in einer ähnlichen Form wie 
die Sprache KL-ONE [2] oder wie das Programmiersystem LOOPS [1]. ObjTalk 
ermöglicht gleichermaßen die Repräsentation von konkreten Fakten und von ab- 
strakten Begriffen in Form einer Wissensbasis von ObjTalk-Objekten. 

• Konkrete Fakten aus einem Problemraum werden repräsentiert durch ObjTalk- 

Objekte und den Werten ihrer Slots. In den Slots von Objekten sind Eigen- 
schaften und Relationen zu anderen Objekten gespeichert. ObjTalk erlaubt die 
Klassifizierung von Objekten: Jedes Objekt gehört zu einer Klasse, als deren 

Instanz es bezeichnet wird. 

• Abstrakte Begriffe werden durch eine besondere Art von ObjTalk-Objekten dar- 
gestellt, durch sogenannte konzeptuelle Objekte : Eine Art von konzeptuellen 

Objekten sind die Klassen , die Abstraktionen ihrer Instanzen darstellen. Alle 
Klassen bilden eine Spezialisierungshierarchie. Klassen besitzen Slotbeschrei- 
bungen, Regeln und Methoden , diese sind ebenfalls konzeptuelle Objekte und 
repräsentieren abstrakte Eigenschaften, Heuristiken und Verhaltensformen losge- 
löst von konkreten Instanzen. 

Jedes ObjTalk-Objekt ist systemintern durch eine Datenstruktur der Im- 
plementationssprache LISP repräsentiert. Der innere Aufbau dieser Datenstruktur 
ist eine Frage der Implementierung von ObjTalk, er soll dem Benutzer verborgen 
bleiben. Entsprechend der objektorientierten Philosophie von ObjTalk können 
aber die Eigenschaften eines Objekts durch das Versenden einer Botschaft erfragt 
oder verändert werden. 
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Wenn ein hochauflösender Bildschirm und ein Zeigeinstrument zur Ver- 
fügung steht, lassen sich Objekte in einer benutzernahen externen Repräsentation 
darstellen: Die Eigenschaften eines Objekts können in einem Bildschirmformular 

dargestellt werden. Die Funktionalität eines Objekts, bestehend aus einer Aus- 
wahl von Botschaften, auf die das Objekt reagiert, kann mit Hilfe eines Menüs vi- 
sualisiert werden. In beiden Fällen erscheint das intern gespeicherte Wissen in der 
Form von zweidimensionalen Objekten auf dem Bildschirm des Computersystems. 

Die externe Darstellung von Wissen durch Bildschirmobjekte muß mit 
der zugehörigen rechnerinternen Repräsentation stets im Einklang stehen. Die 
Aufrechterhaltung der Konsistenz beider Darstellungen ist Aufgabe der Benutzer- 
schnittstelle eines Systems. Von Vorteil ist eine möglichst feste und unmittelbare 
Kopplung zwischen interner und externer Repräsentation, es wird dann eine neue 
Art der Interaktion mit dem System möglich, die als direkte Manipulation [17; 
10] bezeichnet wird: 

• Wenn sich ein internes Datenobjekt ändert, wird dies an einem externen Bild- 
schirmobjekt unmittelbar sichtbar. 

• Der Benutzer kann mit Hilfe eines Zeigeinstruments Veränderungen an der ex- 
ternen Darstellung eines Objekts vornehmen, die sich automatisch auf den in- 
ternen Zustand des Systems auswirken. 

Die Interaktionsform der direkten Manipulation stellt Anforderungen an 
die Form der internen Repräsentation von Wissen: 

• Es muß einfach feststellbar sein, welche internen Zustände von einer Benutzer- 
aktion betroffen sind - am einfachsten ist dies möglich, wenn jedem Bild- 
schirmobjekt ein internes Softwareobjekt zugeordnet ist. In einer objektorien- 
tierten Wissensrepräsentationssprache, wie es ObjTalk ist, läßt sich dies sehr 
einfach erfüllen. 

• Änderungen am intern repräsentierten Wissen dürfen nicht zu teuer sein. In- 
krementelle Änderungen am intern gespeicherten Wissen müssen leicht möglich 
sein und dürfen keinen langwierigen Compilationsvorgang erfordern. Als Wis- 
sensrepräsentationssprache kommt also nur eine Interpretersprache in Betracht, 
was nicht ausschließt, daß festbleibende Teile des Wissens sich dennoch compi- 
lieren lassen. 

• Es muß einen Uberwachungsmechanismus für interne Zustände geben, der be- 
auftragt werden kann, die Benutzerschnittstelle zu aktivieren, wann immer eine 
Zustandsänderung eintritt. Nur so läßt sich gewährleisten, daß die Bildschirm- 
darstellung stets auf dem aktuellen Stand ist. ObjTalk sieht Triggermechanis- 
men vor, welche dies ermöglichen. 
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Die Brauchbarkeit von Benutzerschnittstellen, die auf dem Prinzip der 
direkten Manipulation beruhen, hängt freilich davon ab, wie gut das externe For- 
mat zur Wissensdarstellung den Vorstellungen des Benutzers angepaßt ist. Wenn 
die Bildschirmdarstellungen den Vorstellungen des Benutzers von der realen Welt 
entsprechen, wird es für den Benutzer bedeutungslos, daß es in der Realität, in 
seinen Vorstellungen, auf dem Bildschirm und im Computer verschiedene Reprä- 
sentationen eines Phänomens gibt. Was der Benutzer auf dem Bildschirm sieht 
und womit er am Rechner hantiert, erscheint ihm nicht als ein Abbild, sondern 
als der Gegenstand selber. 

Der Einsatz graphischer Methoden ermöglicht eine externe Wissensdar- 
stellung, die den modellhaften Vorstellungen des Benutzers vom Problembereich 
sehr nahe kommt. Dies hat sich am Erfolg der neuen graphischen Benutzer- 
schnittstellen gezeigt, die erstmals im Büroinformationssystem Xerox Star [18] 
zum Einsatz kamen und heute bereits in einer Vielzahl von Kleinrechnern zu Fin- 
den sind: Die in diesen Systemen gespeicherten Informationen ebenso wie die an- 

wendbaren Operationen zur Informationsverarbeitung sind auf dem Bildschirm 
durch graphische Symbole, sogenannte Piktogramme [19] dargestellt, die der Bü- 
rowelt entstammen; zum Beispiel gibt es Piktogramme, die einen Aktenordner, ei- 
nen Archivschrank, einen Zeilendrucker oder einen Papierkorb symbolisieren. 

Die Darstellung interner Objekte mit Hilfe von Piktogrammen ist sehr 
sinnfällig und ermöglicht die Konstruktion leicht erlernbarer Benutzerschnittstellen. 
Zur externen Darstellung von Wissen wünscht man sich aber eine größere Darstel- 
lungskapazität, als sie der Xerox Star erlaubt: 

• Man möchte nicht nur Objekte aus der Bürowelt darstellen sondern Objekte 
aus beliebigen Gegenstandsbereichen. 

• Es muß möglich sein, beliebige Beziehungen zwischen Objekten graphisch darzu- 
stellen. (Das Star Interface erlaubt nur hierarchische Beziehungen, z.B. zwi- 
schen einem Aktenordner und den in ihm enthaltenen Dokumenten.) 

• Es muß möglich sein, nicht nur konkrete Objekte (wie etwa die Akte XYZ), 
sondern auch abstrakte Begriffe (etwa den Begriff Akte) graphisch darzustellen. 

Es gibt zwar sogenannte Knowledge Engineering Tools, also Werkzeuge 
zur Bearbeitung von Wissensbasen, die im Prinzip diese Anforderungen erfüllen. 
Diese machen aber nur sparsamen Gebrauch von Graphik, wie etwa der Smalltalk- 
Browser [6]. Die Programmiersysteme KEE [11] und LOOPS können nur Verer- 
bungshierarchien von Objekten in graphischer Form veranschaulichen, andere Rela- 
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tionen werden nicht unterstützt. Außerdem können die dargestellten Strukturen 
nicht durch direkte Manipulation verändert werden. Das Simulationssystem 
SIMKIT, eine Erweiterung des KEE-Systems, besitzt zwar eine Benutzerschnittstel- 
le, die vollständig auf direkter Manipulation beruht, es ist aber nur für Simula- 
tionsanwendungen geeignet. Bei der Entwicklung des hier vorgestellten Wissensedi- 
tors ZOO wurde das Ziel verfolgt, die Universalität eines Knowledge Engineering 
Tools mit der Anschaulichkeit einer piktogrammbasierten Benutzerschnittstelle zu 
verbinden. 

3. Graphische Wissensdarstellung im System ZOO 

Gewöhnliche Objekte und konzeptuelle Objekte der Sprache ObjTalk 
lassen sich mit dem System ZOO in graphischer Form darstellen. Zu diesem 
Zweck stehen zwei fundamentale graphische Darstellungsmöglichkeiten zur Verfü- 
gung: Piktogramme und Pfeile. 

Piktogramme bieten eine Vielfalt von Gestaltmerkmalen, mit welchen 
die unterschiedlichen Eigenschaften von Objekten visualisiert werden können: Pik- 

togramme enthalten ein graphisches Symbol und eine Inschrift, Sie haben eine Po- 
sition in der Ebene, besitzen einen Umriß und manchmal eine Umrandung. Grup- 
pen von Piktogrammen können zusammen mit verbindenden Pfeilen Netze bilden. 
Solche Pfeile können eine Beschriftung tragen, sie können sich in verschiedene 
Richtungen gabeln und sie können verschiedene Erscheinungsformen besitzen 
(strichliert, mit Spitzen versehen, verschiedene Linienbreiten). Durch den sinnvol- 
len Einsatz derartiger Gestaltmerkmale kann die Wahrnehmbarkeit von Informa- 
tion entscheidend erhöht werden [13]. 

Im System ZOO dienen Piktogramme zur Repräsentation von Objekten. 
Im Normalfall hat ein solches Piktogramm quadratischen Umriß. Das Piktogramm 
ist mit dem Namen des Objekts beschriftet. Es enthält ein graphisches Symbol, 
das in der Regel die Klassenzugehörigkeit des Objekts verbildlicht. Slots von Ob- 
jekten können auf zwei unterschiedliche Weisen dargestellt werden, abhängig da- 
von, ob sie Relationen zu anderen Objekten oder Attribute darstellen: Relationen 

zwischen Objekten werden durch Pfeile dargestellt, welche die zugehörigen Pikto- 
gramme miteinander verbinden. Die Pfeile sind mit den Namen der Relationen 
(sprich der Slots) beschriftet, die sie repräsentieren. Slots, die keine Objekte als 
Werte aufweisen, also Attribute, können nicht als Pfeile, sondern nur mit Hilfe ei- 
nes Text-Formulars visualiert werden. 




248 




Abbildung 2: Graphische Darstellung des Objekts System-M 
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Abbildung 3: Graphische Darstellung der Klasse Computer 




Abbildung 4: Graphische Darstellung der Slotbeschreibung Producer 
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Konzeptuelle Objekte werden mit dem System ZOO auf ähnliche Weise 
dargestellt wie die gewöhnlichen Objekte, die zur Repräsentation von Fakten die- 
nen. Klassen erscheinen als Piktogramme, die mit einem dicken Rahmen umge- 
ben sind (Abbildung 3). Die Instanzen einer Klasse erhalten in der Regel dasselbe 
graphische Symbol in ihrem Piktogramm wie ihre Klasse. Im System ZOO wird 
die Superklassenrelation ebenso wie die Relationen zwischen gewöhnlichen Objekten 
mit Hilfe beschrifteter Pfeile (” superc ”) dargestellt. Im graphischen Darstellungs- 
format des Systems ZOO übernimmt eine Klasse ohne eigens für sie definiertes 
graphisches Symbol das graphische Symbol ihrer nächsten Superklasse. Die gra- 
phischen Symbole der Piktogramme im System ZOO werden also von einer Klasse 
auf ihre Subklassen und auf ihre Instanzen vererbt und stellen so selbst eine Vi- 
sualisierung des Vererbungsvorgangs dar. 

Im System ZOO sind Slotbeschreibungen durch dick umrahmte längliche 
Rechtecke dargestellt, in denen der Namen des Slots eingetragen ist. Die Relation 
slots , die Klassen und Slotbeschreibungen verknüpft, ist auf ganz normale Weise 
als beschrifteter Pfeil dargestellt. Die Merkmale von Slotbeschreibungen lassen 
sich ebenfalls durch beschriftete Pfeile visualisieren. Abbildung 4 zeigt die graphi- 
sche Darstellung von Abhängigkeitsrelationen zwischen Slots, von Typrestriktionen 
und von Defaults, die für eine Slotbeschreibung kennzeichnend sind. In ähnlicher 
Form stellen sich auch die definierenden Eigenschaften von Methoden sowie die 
beschreibenden Merkmale von Regeln dar. 

4. Der Wissenseditor ZOO 

Das System ZOO läßt sich ansehen als eine Benutzerschnittstelle zum 
gesamten durch ObjTalk-Objekte repräsentierten Wissen eines Softwaresystems. 
ZOO ermöglicht die externe Repräsentation dieses Wissens auf einem hochauflösen- 
den Rasterbildschirm im bereits beschriebenen graphischen Darstellungsformat. Die 
Aufgabe von ZOO besteht darin, beide Wissensdarstellungen, die interne und die 
externe stets miteinander konsistent zu halten. 

Der Kontakt zur internen Wissensrepräsentation wird durch Bildschirm- 
fenster [4] vom Typ ZOO-Window (Abb. 5) hergestellt. Jedes derartige Bild- 
schirmfenster enthält die graphische Darstellung einer Wissensbasis. Ein ZOO- 
Window stellt also die externe Entsprechung einer Wissensbasis dar. 

Die Elemente der externen Wissensdarstellung des Systems ZOO, Pikto- 
gramme und beschriftete Pfeile, sind als graphische Objekte innerhalb eines ZOO- 
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Abbildung 5: ZOO-Windows 



Windows sichtbar. Jedes dieser graphischen Objekte repräsentiert ein Objekt der 
Wissensbasis bzw. eine Eigenschaft eines derartigen Objekts. Jedes dieser graphi- 
schen Objekte kann durch ein Zeigeinstrument (Maus) selektiert werden. Alle ob- 
jektspezifischen Funktionen beziehen sich dann auf die Komponente der Wis- 
senbasis, die durch das das selektierte Bildschirmobjekt dargestellt ist. 
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Die Benutzerfunktionen des Wissenseditors sind durch eine Reihe von 
Piktogrammen dargestellt, die sich auf dem Rand des ZOO-Fensters befinden und 
ebenfalls mit Hilfe der Maus aktiviert werden können. Es stehen alle notwendigen 
Operationen zum Bearbeiten von Wissensbasen bereit: Objekte können durch Ko- 

pieren, Instantiieren oder Spezialisieren des selektierten Objekts erzeugt werden. 
Relationen zwischen Objekten werden definiert durch das Ziehen von Pfeilen vom 
selektierten Objekt zu anderen Objekten. Die Namen dieser Relationen können 
aus einem Pop-Up-Menü ausgewählt werden, dessen Inhalt aus der Klasse des se- 
lektierten Objekts abgeleitet ist. Darüberhinaus gibt es Funktionen zum Abspei- 
chern und Laden von Wissensbasen, zum Betrachten von Objekten, zum Löschen 
von Objekten, zum Vergessen von Relationen und zum Verändern von Position 
und Erscheinungsbild von Objekten. 

Die Selektionen von Objekten und das Auslösen von Anwenderfunktio- 
nen des Systems erfolgen also stets über Zeigehandlungen, wobei nur ein Knopf 
der Maus, nämlich der linke, betätigt werden muß. Dies macht den Umgang mit 
dem System sehr einfach. Dabei erfolgt die Interaktion mit dem System nach der 
Noun-Verb- Syntax : Es muß zuerst ein Objekt bezeichnet werden, und dann erst 

die Operation, die auf das Objekt angewandt werden soll. Dies hat den Vorteil, 
daß die Interaktion weitgehend ohne besondere System-Modi [20] erfolgt. Nach 
der Selektion eines Objekts gerät man nicht in einen besonderen Systemzustand, 
der die Angabe einer Operation zwingend erfordert. Auf eine irrtümliche Selek- 
tion eines Objekts kann jederzeit eine weitere Selektion folgen. Umgekehrt kann 
auch nach dem Auslösen einer Anwenderfunktion sofort eine zweite betätigt wer- 
den, wenn sie sich auf das bereits selektierte Objekt bezieht. 

Die Verwaltung der graphischen Objekte eines ZOO-Windows geschieht 
nicht an einer zentralen Stelle, vielmehr erfolgt sie in objektorientierter Weise ver- 
teilt auf viele aktive Instanzen: Jedes Piktogramm, jeder Pfeil, jede Pfeilbeschrif- 

tung ist selbst durch ein ObjTalk-Objekt, ein sogenanntes Interaktionsobjekt [8], 
repräsentiert. Interaktionsobjekte stellen die Kopplung her zwischen internen Wis- 
sensbasisobjekten und ihren graphischen Darstellungen auf dem Bildschirm. In 
den Interaktionsobjekten sind daher zwei Arten von Wissen repräsentiert: 

• Interaktionsobjekte besitzen graphisches Wissen: Jedes Interaktionsobjekt be- 

schreibt die Lage und Gestalt eines auf dem Bildschirm erscheinenden graphi- 
schen Objekts. Dieses Wissen ist gleichermaßen von Bedeutung für das opti- 
sche Erscheinungsbild des Interaktionsobjekts wie für die Möglichkeit der Akti- 
vierung desselben mit Hilfe eines Zeigeinstruments. 




252 



• Interaktionsobjekte besitzen Wissen über Wissensbasisobjekte: Jedes Interak- 

tionsobjekt weiß um die Existenz oder um die Eigenschaften des Wissensbasis- 
objekts, das es nach außen hin vertritt. Darüberhinaus stellen Interaktions- 
objekte ein Medium dar zur Manipulation der internen Wissensbasisobjekte. 

Die hauptsächliche Funktion des Systems ZOO, nämlich die Darstellung 
des Inhalts einer Wissensbasis mittels direkt manipulierbarer graphischer Objekte 
in einem Bildschirmfenster, läßt sich somit folgendermaßen darstellen: Der Ver- 

wendungszweck des Systems ZOO besteht darin, zu einer Wissensbasis über einen 
bestimmten Problemraum eine zweite Wissensbasis bestehend aus Interaktionsob- 
jekten, eine sogenannte ZOO -Wissensbasis, zu generieren. Eine solche ZOO- 

Wissensbasis stellt gleichermaßen eine Beschreibung der internen Objekte einer 
Problemwissensbasis und der externen graphischen Objekte auf einem ZOO- 
Window dar (siehe Abbildung 6). 
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Die im System ZOO zur Darstellung von Wissensbasen verwendeten In- 
teraktionsobjekte sind im wesentlichen Spezialformen sogenannter Icons aus dem 
Interaktionspaket ICONS [7] . Icons sind Interaktionsobjekte, die auf dem Bild- 
schirm in der Regel als beschriftete Piktogramme erscheinen. Icons verfügen über 
eine sogenannte Aktion, die ausgeführt wird wenn das Icon mit der Maus aktiviert 
wird, sowie über einen Pointer auf das von ihnen repräsentierte Objekt. Im Sy- 
stem ZOO wurden drei Icon-Klassen definiert, dabei handelt es sich um soge- 
nannte Object-Pictures zur Darstellung von gewöhnlichen Objekten, Class-Pictures 
zur Darstellung von Klassen und Slot-Pictures zur Darstellung der Slots von Ob- 
jekten. Außerdem gibt es zwei Klassen von Linienelementen zum Darstellung von 
Pfeilen: sogenannte Hooked-Links zum Zeichnen von Pfeilspitzen und Links zum 

Zeichnen von Pfeilenden. 

Auch die Funktionssymbole auf dem Rand eines ZOO-Windows sind 
durch spezielle Icons repräsentiert. Diese Icons dienen aber nicht direkt zur Vi- 
sualisierung von Wissensbasisobjekten. Vielmehr haben sie die Aufgabe, die An- 
wendungsfunktionen des Systems ZOO zu visualisieren. Die meisten Anwendungs- 
funktionen haben das selektierte Objekt zum Gegenstand und sind in Form von 
Methoden der Object-Pictures, Class-Pictures oder Slot-Pictures definiert. Die Ak- 
tion, die mit dem Anklicken eines Funktionssymbols verbunden ist, besteht daher 
lediglich im Versenden einer Botschaft an das selektierte Icon im Innern des ZOO- 
Windows. Die Reaktion auf diese Botschaft ist abhängig davon, ob ein Object- 
Picture, ein Class-Picture oder ein Slot-Picture selektiert ist, da diese Icons auf die 
gleichen Botschaften in unterschiedlicher Weise reagieren. So kommt das System 
ZOO mit einer relativ kleinen Anzahl von Anwendungsfunktionen aus, durch die 
Typabhängigkeit des Systemverhaltens ist die Benutzerschnittstelle trotz ihrer Ein- 
fachheit genügend mächtig. 

Implementation 

ZOO läuft auf einer VAX 11/780 unter Berkeley UNIX 4.2 und benö- 
tigt ein BBN BitGraph Terminal als Bildschirmgerät. ZOO macht Gebrauch von 
der objektorientierten Sprache ObjTalk [14], vom Fenstersystem WLISP [4] und 
von den Interaktionspaketen ICONS [7] und NETS [15]. Implementationsspra- 
che aller Softwarekomponenten ist Franz Lisp [5]. 
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5. Zusammenfassung 

Die Berücksichtigung von Wissensaspekten ermöglicht eine neue Sicht- 
weise der Mensch-Computer-Kommunikation. Das Problem, verständliche Benut- 
zerschnittstellen zu konstruieren, stellt sich dar als die Frage nach einer benutzer- 
gerechten externen Wissensrepräsentation, und ist eng verbunden mit dem Prinzip 
der direkten Manipulation. 

Direkte Manipulation beruht auf der externen Repräsentation von Wis- 
sen, die eng gekoppelt sein muß mit der internen Wissensdarstellung. Große Vor- 
teile bietet hier eine integrierte objektorientierte Systemarchitektur, die den Sy- 
stemkern und die Benutzerschnittstelle gleichermaßen umfaßt. Eine objektorien- 
tierte Benutzerschnittstelle ermöglicht den Einsatz von Interaktionsobjekten, die 
sich nach außen hin als sensitive Bildschirmobjekte zur externen Wissensrepräsen- 
tation zeigen, nach innen hin aber aktive Datenstrukturen sind, die mit den inter- 
nen Objekten zur Wissens rep r äsen tation kommunizieren. Mit einer objektorientier- 
ten internen Wissensrepräsentation haben die Interaktionsobjekte der Benutzer- 
schnittstelle eine eindeutige interne Entsprechung und eine enge Kopplung beider 
Darstellungen wird möglich. 

Das Objekt als fundamentales Konzept der Programmierung und Wis- 
sensrepräsentation ermöglicht die einfache Konstruktion von Metasystemen, mit de- 
nen Fakten und Konzepte des Systems visualisiert und vom Benutzer modifiziert 
werden können. 

Der objektorientierte wissensbasierte Ansatz, verbunden mit fortgeschrit- 
tenen Techniken der Mensch-Computer-Kommunikation ermöglicht so die Kon- 
struktion besser durchschaubarer und in weiten Teilen vom Benutzer adaptierbarer 
Anwendungsprogramme und leistet so einen entscheidenden Beitrag zur Gestaltung 
benutzergerechter Computersysteme. 
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ENTSCHEIDUNGSTABELLEN UND EXPERTENSYSTEME 

Vergleich und wechselseitige Überführung 

U. GUntzer, Ch. Schöll, G. Jüttner, K * R . Moll 



Sc h Mia« A w g P -t e . r 

Entscheidungstabellen, Expertensysteme, Software Technologie 
Zusammenfassung 

In jüngster Zeit entwickelten sich die Expertensysteme als eine 
Anwendung der Wissensverarbei tung zu einem neuen, heftig disku- 
tierten Teilgebiet der Informationsverarbeitung. Von den Anhän- 
gern der Expertensysteme wird hierin ein wesentlicher Durch- 
bruch in der Inf ormationstechnologie erwartet, manche Kritiker 
sagen hingegen, es handle sich nur um einen neuen Namen für 
altbekannte Verfahren, wie z.B. die Entscheidungstabellentech- 
nik . 

In einem gemeinsamen Projekt der Bayerischen Hypotheken- und 
Wechselbank München, dem Institut für Informatik der TU München 
und dem Leibniz-Rechenzentrum der Bayerischen Akademie der Wis- 
senschaften wird anhand von Anwendungsbeispielen die Frage un- 
tersucht, worin die praxisbezogenen Unterschiede zwischen der 
konventionellen Programmierung mit Entscheidungstabellen und 
der wissensbasierten Programmierung in Form der Expertensysteme 
liegen . 

Als Grundlage hierfür dienen Aufgabenstellungen aus der Praxis 
des Bankwesens, zum einen die Filialen einer Bank zu analysie- 
ren und zum anderen die Kreditwürdigkeit zu prüfen. Die Filial- 
analyse ist wissensbasier t als Prototyp-Expertensystem in 
IF/Prolog /l/ und zusätzlich mit Hilfe des Expertensystem- 
Shells PERSONAL CONSULTANT PLUSC PC+ ) implementiert /5/. Zum 
Vergleich erfolgte mit Hilfe von PL/1 und Entscheidungstabellen 
eine konventionelle Programmierung des Filialanalysesystems 
/5/. Die Kreditwürdigkeitsprüf ung ist wissensbasiert mit PC+ 
/2/ und konventionell mit PL/1 und Entscheidungstabellen /5/ 
implementiert . 

Ausgehend von der gleichen Mächtigkeit beider Programmierpara- 
digmen werden in der vorliegenden Arbeit verschiedene Kriterien 
wie Progr ammier auf wand , Entwicklungsfreundlichkeit, 
Wartbarkeit, Laufzeitverhalten, Ablaufsteuerung und Erklärungs- 
fähigkeit der einzelnen Programme miteinander verglichen und 
die Vor- und Nachteile der beiden Progr ammiertechniken be- 
schrieben. Aufbauend auf diesen Vergleich werden 
Entscheidungshilfen für die Frage *Soll man ein System konven- 
tionell mit Entscheidungstabellen oder wissensbasiert als 
Expertensyst em entwickeln* gegeben. 
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Basierend auf diesen Ergebnissen wird in einem weiteren Teil 
der Arbeit dargestellt/ wie ein konventionelles Entscheidungs- 
tabellenprogramm in ein Expertensystem transf ormiert werden 
kann und inwieweit der umgekehrte Weg möglich ist. Diese Trans- 
formationen schaffen die Möglichkeit# die Vorteile der wissens- 
basierten und der konventionellen Programmiertechnik sowohl bei 
der Erstellung als auch beim Einsatz von Sof twaresystemen wech- 
selweise auszunutzen. Damit wird die Grundlage geschaffen# 
einerseits Problemlösungen in vereinf achter Weise als Experten- 
system zu entwickeln und mit Hilfe von Entscheidungstabellen 
effizient zum Einsatz zu bringen und andererseits bestehende 
Entscheidungstabellen als Expertensysteme weiterzuentwickeln. 
Anhand der bei den manuellen Transformationen gewonnenen Erfah- 
rungen werden schließlich systematische Wege gesucht# die den 
Transformationsvorgang vereinfachen. 

1.0 Beschreibung konventioneller und wissensbasierter Program- 
miertechniken 



1.1 Konventionelle Datenverarbeitung 

Bei der konventionellen Datenverarbeitung ist der Systement- 
wickler für den Programmablauf verantwortlich # d.h die Reihen- 
folge der Verarbei tungsschr i tte muß für jede Eingabekonstella- 
tion im Voraus betrachtet werden und explizit im Programmcode 
ber ücksichtigt werden. Dies hat zur Folge# daß Daten# Wissen 
über die Problemlösung und Wissen über die Steuerung der Anwen- 
dung dieses Wissens im Algorithmus miteinander vermischt 
werden# was nicht nur bei der Erfindung des Algorithmus Schwie- 
rigkeiten bereitet# sondern immer dann# wenn das im Algorithmus 
verkörperte Wissen explizit benötigt wird: zur Erklärung# zur 
Schulung# zur Abänderung# zur Übertragung auf ähnliche Situa- 
tionen . 

Die konventionelle Datenverarbeitung wird überwiegend bei Pro- 
blemen angewandt# für deren Lösung ein Algorithmus bekannt ist( 
z.B. numerische Berechnungen ) und wo die zugrundeliegende 
Software nur wenigen Änderungen unterliegt. 

1.2 Entscheidungstabellen 

Die Programmierung mit Entscheidungstabellen ist eine häufig 
angewandte Methode der konventionellen Programmierung . Der 
Entwur f sprozeß läuft dabei in zwei Schritten ab. 

Zunächst wird das Problem in Entscheidungsbäume zusammengefaßt# 
im Anschluß daran erfolgt die Umwandlung von bestimmten Teil- 
bäumen in verschiedene Entscheidungstabellen. Diese Zweistufig- 
keit erfordert zwar gegenüber der sonstigen konventionellen 
Programmerstellung einen erhöhten Zeitaufwand# hat aber den 
Vorteil# daß mit der Erzeugung von Entscheidungstabellen eine 
Prüfung auf Vollständigkeit# Widerspruchsf reiheit und Redun- 
danzfreiheit automatisch durchgeführt werden kann. Dadurch 
werden funktionale Fehler vermieden. 
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Beim Sequentialisierungsprozeß werden die Entscheidungstabellen 
in ein konventionelles Programm eingegliedert. Dabei werden die 
Teile des Entscheidungsbaumes * die nicht in Entscheidungstabel- 
len formuliert sind* vom Programmersteller in den Code einer 
Programmiersprache Uberführt. Die Entscheidungstabellen selbst 
werden mit Hilfe eines Entscheidungstabellengenerators automa- 
tisch codiert. 

Entscheidungstabellen werden Überwiegend im kaufmännischen Be- 
reich eingesetzt* um eine Schnittstelle zwischen den Kaufleuten 
als Aufgabenstellern und den Programmentwicklern zu haben. Der 
Kaufmann formuliert dabei sein Wissen in Entscheidungstabellen. 
Dadurch fällt für den Entwickler ein Teil des Entwurfsprozesses 
weg und er muß sich nur noch um die Sequentialisierung der Ent- 
scheidungstabellen untereinander kümmern. 
Entscheidungstabellen werden hingegen selten eingesetzt* wenn 
Berechnungen aufgrund bekannter Algorithmen möglich sind /6/. 

1.3 Wissensverarbeitung 

Ein erheblicher Vorteil der Wissens Verarbeitung liegt in ihrem 
vereinfachten Entwur f sprozeß . Die einzelnen Wissenseinheiten 
werden in elementarer Form festgelegt und im Idealfall in be- 
liebiger Reihenfolge auf geschrieben . Die Sequentialisierung 
führt dann ein Interpreter (Inferenzprozeß) selbständig aus* 
dabei wird das explizit vorliegende Wissen verarbeitet. 

Die Vermischung von Daten* Wissen über die Problemlösung und 
Wissen über die Steuerung der Anwendung dieses Wissens wird in 
diesem Paradigma vermieden. Der Lösungsweg wird von dem Infe- 
renzmechanismus selbständig gesucht. 

Diese Form der Pr ogr ammierung hat die Vorteile* daß die Pro- 
grammentwicklung aufgrund der Modularisierung vereinfacht wird 
und dadurch das System schrittweise entwickelbar und auch 
leichter veränderbar ist. Durch die explizite Formulierung des 
Wissens Uber die Problemlösung wird das zugrundeliegende Lö- 
sungsmodell diskutierbar und eine Erklärung des Lösungsweges 
vereinfacht* ja sogar automatisierbar. Das wissensbasierte 
Programm ist im Idealfall sogar seine eigene Dokumentation. 

Als Anwendungsgebiete der Wissenverarbeitung gelten die Berei- 
che Diagnose* Beratung* Schulung und Konfiguration, überwiegend 
wird sie im Sinne des Rapid Prototyping dort eingesetzt* wo 
Argumentationen und Schlußfolgerungen an Stelle von Berechnun- 
gen notwendig sind/4/. 
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Die Abbildungen 2a und 2b verdeutlichen den Unterschied zwi- 
schen Sachwissen (Wissen über die Problemlösung) und Kontroll- 
wissen (Wissen über die Anwendung des Sachv/issens ) innerhalb 
der Wissensverarbeitung . Das Sachwissen 'weiß/ was' die Lösung 
ist (know what). Das Kontrollwissen 'weiß/ wie' die Lösung ge- 
funden wird (know how). Letzteres bestimmt/ welche 
Regelgruppen geprüft werden/ wann ein Regelgruppenwechsel voll- 
zogen wird und wann dieselbe Regelgruppe mehrmals geprüft 
werden muß. Schleifen und Rekursionen werden ebenfalls durch 
das Kontrollwissen ausgedrückt. Das Sachwissen (Sachregeln) 
muß nicht notwendigerweise in Regelgruppen zusammengefaßt sein. 
Diese erhöhen aber die Übersichtlichkeit und Abarbeitungseffi- 
zienz . 

Bei der Entscheidungstabellentechnik ( Abb.lb ) ist Sach- und 
Kontrollwissen ebenfalls getrennt. Das Sachwissen ist notwendi- 
gerweise in Regelgruppen ( Entscheidungstabellen ) zusammenge- 
faßt. Das Kontrollwissen entspricht dem Programmablauf plan und 
ist außerhalb der Entscheidungstabellen verschlüsselt und nicht 
explizit sichtbar. Schleifen/ Rekursionen und Regelgruppen- 
wechsel werden durch den Ablaufplan des Programms bestimmt und 
liegen i.A. außerhalb der Entscheidungstabellen im umgebenen 
Programm . 

Die komplette Vermischung des Sachwissen mit dem Kontrollwissen 
ist in Abb.la zu erkennen. Hier ist das Sachwissen auch in den 
Programmcode integriert und unt e rscheidet sich dadurch nicht 
mehr vom Kontrollwissen. 

2.0 Vergleich der Programmiertechniken 

In diesem Kapitel werden im wesentlichen die praktischen Erfah- 
rungen beschrieben/ die bei der wissensbasierten Implementie- 
rung von Expertensystemen im Vergleich zur Implementierung von 
konventionellen Systemen mit Hilfe von Entscheidungstabellen 
gemacht wurden. 

Grundlage für diesen Vergleich ist zunächst ein System/ welches 
Experten bei der Analyse von Filialen unterstützt. Die konven- 
tionelle Realisierung dieser Aufgabe wurde mit Hilfe der Pro- 
grammiersprache PL/1 und dem Entscheidungstabellengenerator 
VORELLE auf einer IBM-Großrechenanlage vorgenommen. Die wis- 
sensbasierte Programmierung dieser Aufgabe wurde zum einen mit 
Hilfe von IF/Prolog und zum anderen mit Hilfe des Shells PC+ 
/I / durchgeführt/ um den Ablauf eines konventionellen Programms 
mit verschiedenen von Expert ensystemen verwendeten Inferenzme- 
chanismen vergleichen zu können. Zur Bekräftigung der 
Vergleichsergebnisse wurde ein System/ welches einen Kredit- 
sachbearbeiter bei der Vergabe eines Kredits unterstützt/ 
konventionell ebenfalls mit PL/1 und VORELLE implementiert und 
wissensbasiert mit PC+. 

Im nachfolgenden Teil der Arbeit wird in erster Linie die kon- 
ventionelle Entscheidungstabellentechnik mit den mit PC+ ent- 
wickelten Systemen verglichen. Der Vergleich mit einem Prolog- 
System bringt im wesentlichen Erkenntnisgewinne bzgl. des Infe- 
renzmechanismus. 
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2.1 Entwicklungsvorgang 

Bei konventionellen Systemen mit Entscheidungstabellen wird der 
gesamte Entwicklungsvorgang von den Daten ausgehend durchge- 
führt. Um ein Problem zu lösen wird überlegt* welche Daten 
vorliegen* wie diese strukturiert werden* welche Berechnungen 
mit diesen Daten ,vorzunehmen sind* welche Aktionen dann vollzo- 
gen werden müssen und wie diese Aktionen in Regeln auszudrUcken 
sind. Es liegen viele Regeln in ungeordneter Form vor. Diese 
Regeln werden dann in Entscheidungstabellen zusammengefaßt. Der 
Programmentwickler verbindet im Anschluß daran die Entschei- 
dungstabellen zu einem sequentiellen Programmablauf • 

Bei Expertensystemen ist die Ausgangslage eine andere. Hier 
wird der Entwicklungsvorgang insbesondere bei Backward-Chai- 
ning-Systemen * wie im Falle von PC+* vom Ziel des Systems aus 
betrachtet* das als GOAL deklariert wird. Es werden alle Prä- 
missen bestimmt* die zur Erfüllung des Goals beitragen. Aus den 
verschiedenen Bedingungskonstellationen werden dann Regeln 
festgelegt* die zum Goal hinführen. Danach werden alle Prämis- 
sen der Goals ebenfalls als Ziele betrachtet ( Subgoals ). Nun 
werden analog zur Erfüllung des Hauptgoals alle Prämissen ge- 
sucht* die zur Erfüllung der Subgoals führen. 

Als Ergebnis der Expertensystementwicklung liegt ähnlich wie 
bei den Entscheidungstabellen eine Menge ungeordneter Regeln 
vor. Diese werden nun nicht weiter umgesetzt* sondern bilden 
insgesamt die Wissensbasis des Expertensystems. Um die richti- 
ge Abarbeitung der Regeln kümmert sich der Inf erenzmechanismus . 
Der Entwickler muß jedoch durch gewisse MaßnahmenC Gewichtung 
der Regeln* Metaregeln* Anordnung der Regeln ) die Regelabar- 
beitung beeinflußen* um das gewünschte Ergebnis zu erhalten. 
Diese Entwicklungsmethode wird vereinfacht durch die Tatsache* 
daß hier inkrementeil vorgegangen werden kann. Auch wenn erst 
ein Teil der Regeln vorliegt* ist das zu entwickelnde Programm 
ohne Einbettung in ein konventionelles Steuerungssystem lauffä- 
hig. 

2.2 Entwicklungsaufwand und Hilfsmittel 

Beim konventionellen System wurde während der Entwicklungsphase 
die meiste Zeit für die Neukompilierung nach Programmändarungen 
gebraucht. Auch die Fehlersuche wurde dadurch erschwert* daß im 
Falle des vorliegenden PL/l-Compi lers kein spezielles Debugging 
möglich war. Als nützliches Hilfsmittel erwies sich der Ent- 
scheidungstabellengenerator VORELLE* der Entscheidungstabellen 
analysiert und dadurch Fehler aufdeckt. 

Bei der wissensbasierten Entwicklung der Filialanalyse mit PC+ 
erwies sich die Suche nach einer geeigneten Datenst ruktur auf- 
grund mangelnder Ausdrucksmöglichkeiten des Shells am zeitauf- 
wendigsten. Erwei terungen konnten im Sinne des Rapid Prototy- 
ping sofort getestet werden und durch die Möglichkeit der Ver- 
folgung der Regelabarbeitung ( TRACE-Mechanismus ) war ein 
hervorragendes Debugging möglich. Auch eventuelle Tippfehler 
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und logische Fehler wurden vom Shell sofort erkannt. Die mei- 
ste Entwicklungszeit sparte man allerdings durch die 
Modularität des Wissens innerhalb des Expertensystems . Dadurch 
konnten Erwei terungen mit bedeutend weniger Nachdenkzeit vorge- 
nommen werden. 

2.3 Darstellung der Fakten und des Wissens 

Bei der Filialanalyse liegen relativ viele Daten vor( Kennzahl- 
werte, Kennzahlbaum, Gewichtungen der Kennzahlen ) und es wer- 
den viele Berechnungen mit Hilfe dieser Daten vorgenommen. 
Aufgrund der großen Zahl unterschiedlicher Daten ist es nütz- 
lich, die zusammenhängenden Werte in eine geeignete Datenstruk- 
tur zu integrieren. 

Dies ist mit den konventionellen Mitteln einfach durchführbar, 
man kann hier auf Felder und Recordst rukturen zurückgreifen. 
Diese Möglichkeit gibt es in der Regel bei Expertensystem- 
Shells noch nicht, so daß die zur Filialanalyse herangezogenen 
Daten nur sehr ungünstig in Form elementarer Variablen gespei- 
chert werden können. Dies hat wiederum zur Folge, daß manche 
Abarbeitungsregeln komp lizier ter sind, da man nicht selektieren 
und indizieren kann. 

Für die Darstellung des Wissens wurden keine wesentlichen Un- 
terschiede festgestellt. Regeln werden in Entscheidungstabellen 
ähnlich dargestellt wie Sachwissen in Expertensystemen (vgl.lb, 
2a, 2b ). Bei Entscheidungstabellen ist allerdings darauf zu 
achten, daß eine Regel sich in der richtigen Entscheidungsta- 
belle befindet, d.h. richtig im Ablaufplan des Programms liegt. 
Dies ist jedoch auch bei manchen Hilfsmitteln zur Erstellung 
von Expertensystemen , z.B bei Prolog, nötig. 

2.4 Inf erenzmechanismen , Steuerung des Programms 

2.4.1 Inferenzmechanismus der Entscheidungstabellen 

Im konventionellen Programm mit Entscheidungstabellen legt der 
Entwickler an Stelle eines nicht vorhandenen Inferenzmechanis- 
mus die Abarbeitung der Aktionen durch den Programmablauf plan 
fest Cvgl. Abb.lb ). Er bedient sich dabei der Forward-Chai- 
ning-St rategie , nach der Aktionen ausgeführt werden, wenn sie 
im sequentiellen Programmablauf an der Reihe sind. Der Ent- 
wickler bestimmt auch, wann eine Entscheidungs tabeile 
aufgerufen wird, jedoch durch den Aufruf einer Entscheidungsta- 
belle gibt er die Steuerung des Programms kurzfristig ab. Diese 
übernimmt dann der Inferenzmechanismus der 
Entscheidungstabelle, welcher folgendermaßen abläufts 

Nach dem Prinzip des Forward-Chainings werden die Prämissen der 
Regeln untersucht und bei Erfüllung aller Prämissen einer Regel 
wird diese angewendet. Bei Eint ref f er-Entscheidungstabellen 
werden die Regeln der Reihe nach getestet und sobald eine Regel 
anwendbar ist, wird diese ausgeführt. Die restlichen Regeln 
werden nicht mehr überprüft. Bei Mehrtref f er-Entscheidungsta- 
bellen dagegen werden alle anwendbaren Regeln ausgeführt. Dies 
bedeutet, daß auf jeden Fall alle Regeln einer aufgerufenen 
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Entscheidungstabelle getestet werden. Es besteht jedoch nicht 
die Möglichkeit» diesen Inferenzmechanismus während des Pro- 
grammlaufs zu beeinflußen. Der Inferenzmechanismus arbeitet die 
anwendbaren Regeln sequentiell ab und kommt deshalb bei Regel- 
umstellungen möglicherweise zu ganz anderen Ergebnissen. 

2.4.2 Vergleich mit dem Prolog-Inf erenzmechanismus 

Der Inferenzmechanismus des Prolog-Interpreters funktioniert 
ähnlich» denn auch hier wird von mehreren anwendbaren Regeln 
diejenige ausgeführt» die zuerst getestet wurde. Jedoch arbei- 
tet der Prolog-Interpreter nach der Backward-Chaining-Methode . 
Die Regelabarbeitung des Interpreters erlaubt nicht» Regeln 
beliebig zu vertauschen. Der nahezu lineare Lösungsweg des 
Filialanalysesystems verursachte eine feste Reihenfolge der 
Regelabarbeitung» was die Nachimplementierung mittels Entschei- 
dungstabellen vereinfacht hat. 

2.4.3 Vergleich mit dem Inf erenzmechanismus von PC+ 

Der Inferenzmechanismus von PC+ bietet die Möglichkeit» von 
mehreren anwendbaren Regeln eine ganz bestimmte anzuwenden. 
Diese Beeinflußung des Inferenzprozeßes während des Programm- 
laufs wird zusätzlich durch Regelgewichtungen und Metaregeln 
unterstützt. Weitere Hilfsmittel erlauben» mehrere Regeln anzu- 
wenden C Antecedent-Regeln » Active-Values) /7/. Dieser 
Inferenzmechanismus arbeitet i.a. nach der Backward-Chaining- 
Strategie. Es besteht aber die Möglichkeit Regeln mit 
ANTECEDENT zu kennzeichnen» um eine vorwärtsger ich tete Abarbei- 
tung zuzulassen. 

2.5 Laufzeitaufwand 



Aus der Beschreibung der Inferenzmechanismen ist 
offensichtlich» daß die Laufzeit beim konventionellen System 
i.A. geringer ist. Bei Expertensystemen wird der Prog r ammablau f 
vom Inferenzmechanismus 'gesucht'» dagegen wird bei konventio- 
nellen Systemen mit Entscheidungstabellen der Programmablauf 
bereits durch den Entwickler bestimmt. Während beim Experten- 
system meistens viele Regeln getestet werden» werden beim 
konventionellen System immer nur die Regeln einer bestimmten 
Entscheidungstabelle getestet» also bedeutend weniger. Außerdem 
können bei Eintreffer-Entscheidungstabellen Regelminimierungen 
vorgenommen werden» was einen zusätzlichen Lauf Zeitgewinn be- 
deutet. Hier bieten sich jedoch auf Seiten der Expertensysteme 
Ansätze zur Ef f izienzverbesserung durch die Bildung von Regel- 
gruppen an Cvgl. Abb. 2a» 2b). 

Eine Lauf zeit Verbesserung wird außerdem durch eine geeignete 
Regelreihenfolge erreicht. Die Reihenfolge der Regeln wird da- 
bei durch die Häufigkeit der Anwendung bestimmt. Bei Entschei- 
dungstabellen und auch bei Expertensystemen kann die 
Häufigkeit» wie oft eine Regel gefeuert wurde, festgestellt 
werden. Mit diesem Wissen kann man Regeln, die häufig gefeuert 
werden, am Anfang der Regelabarbeitung einbauen. 
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Weiterhin wird die Laufzeit von Programmen durch die Wahl des 
Rechners beeinflußt. Im konkreten Fall wurden die konventio- 
nellen Systeme auf einem Großrechner implementiert/ die Exper- 
tensysteme hingegen auf einem Kleinrechner/ weswegen absolute 
Laufzeitvergleiche wenig sinnvoll sind. 

2.6 Änderungsf reundlichkeit 

Änderungen an einem Expertensystem geschehen durch Abändern 
oder Neuhinzuf ügen einer Regel. Dabei muß unter Berücksichti- 
gung des Inf erenzprozeßes beachtet werden/ daß neue Regeln zum 
richtigen Zeitpunkt getestet werden. Diese Art der Programmän- 
derung ist relativ einfach und kann im Sinne des Rapid-Prototy- 
ping auch schnell vollzogen werden/ da aufgrund der Modularität 
des Wissens der Einarbeitungsprozeß in das zu ändernde System 
vereinfacht wird. 

Änderungen in Entscheidungstabellen geschehen ähnlich wie bei 
den regelbasierten Systemen/ indem eine neue Regel in eine Ent- 
scheidungstabelle hinzugefügt wird oder eine alte Regel geän- 
dert wird. Größere Probleme treten jedoch bei Änderungen im 
Steuerungsteil des Programms auf. Während bei regelbasierten 
Systemen auch hier nur eine Änderung oder Hinzufügung einer 
Regel vorgenommen werden muß/ so ist bei konventionellen Pro- 
grammen außerhalb der Entscheidungstabellen direkt im Programm 
diese Änderung vorzunehmen/ was er f ahr ungsgemäß schwieriger zu 
verwirklichen ist. 

Entscheidungs tabellen stellen das Wissen explizit/ der Pro- 
g r ammablauf plan stellt das Wissen implizit dar. So gesehen 
kann man die Programmierung mit Entscheidungstabellen in ihrer 
Änderungsf reundlichke i t zwischen der regelbasierten/ wo das 
Wissen explizit dargestellt ist/ und der konventionellen Ent- 
wicklung ansiedeln/ wo das Wissen implizit integriert ist. 

2.7 Erklärungsfähigkeit 

Soll ein Pr ogrammsystem seine Schlußfolgerung dem Anwender er- 
klären/ so muß dies bei der konventionellen Programmiermethode 
explizit ausprogr ammier t werden/ während unter zu Hilfenahme 
einer Expertensystem-Shell mit integrierter Erklärungskomponen- 
te dies nicht notwendig ist. Bei PC+ kann eine eingebaute Er- 
klärungskomponente verwendet werden/ um dem Benutzer zu 
erklären/ warum und wie es zum gegenwärtigen Ergebnis gekommen 
ist. 

2.8 Folgerungen aus dem Vergleich 

In der Funktionalität und in der Mächtigkeit der f ertiggestell- 
ten Systeme wurden bis auf die Erklärungskomponente keine Un- 
terschiede festgestellt. Hierdurch wird eine bereits von E. 
Kowalski vertretene Meinung unterstützt/ daß die Macht der Ex- 
pert ensys teme in ihrem Entwicklungsprozeß liegt und nicht im 
Endsystem/ welches wenn es vollständig und verstanden ist/ auch 
mit einem konventionellen System implementiert werden kann/3/. 
D.h. also/ daß die wissensbasierte Programmierung eine neue 
Software-Entwicklungs-Technologie darstellt. 
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Die daraus entstehende Frage *Soll man ein System konventionell 
mit Entscheidungstabellen oder wissensbasiert als Expertensy- 
stem implementieren* wird Überwiegend durch die Jeweiligen Voi — 
teile der Programmiertechniken bestimmt. 

Aus der Modularität des Wissens ergeben sich bei der wissensba- 
sierten Entwicklung Vorteile im Entwicklungsaufwand» der Xnde- 
rungsf reundlichkeit und in der Erklärungsfähigkeit. Daraus 
folgt» daß ein System wissensbasiert entwickelt werden sollte» 
wenn einige der folgenden Kriterien erfüllt sind: 

- es existiert kein Algorithmus zur Lösung des Problems 

- Problem noch nicht vollständig erschloßen (diffuse Gebiete) 

- Laufzeit spielt geringe RolleC z.B. viele Benutzereingaben ) 

- Ergebniserklärung gewünscht 

- guter Systemüberblick gewünscht 

- Wartbarkeit und Änderungen wichtig 

- Übertragungen auf ähnliche Aufgabengebiete vorgesehen 

Es gibt aber auch Gründe» die für eine Entwicklung mit konven- 
tionellen Mitteln sprechen. Vorteilhaft von konventionellen 
Systemen ist in erster Linie die Laufzeit. Darum ergeben sich 
folgende Kriterien» die für eine Entwicklung mit konventionel- 
len Methoden sprechen: 

- Bekannter Algorithmus 

- viele numerische Berechnungen sind vorzunehmen 

- es liegen wenig Benutzereingaben vor 

- Laufzeit spielt wichtige Rolle 

- Benutzer interessiert primär das Ergebnis» nicht der Weg 

- Black-box-Betrachtungsweise 

- keine oder nur geringe Änderungen sind zu erwarten 

3.0 Transformation der Programmiertechniken 

Unter der Transformation der Pr ogrammiertechniken wird die 
Überführung eines mit einer Programmiertechnik entwickelten 
Systems in ein funktional gleichwertiges System einer anderen 
Programmiertechnik verstanden. Dabei geht es nicht um einen 
abstrakten Mächtigkeitsvergleich » sondern das Ziel dieser 
Transf ormationen ist es» die jeweiligen Vorteile der einzelnen 
Programmiertechniken wechselweise ausnützen zu können. 

3.1 Transformation von Entschteidungstabellen in Expertensyste - 
me 

3.1.1 Vorgehen bei der manuellen Transformation 

Bei der Überführung von Entscheidungstabellen in ein regelba- 
siertes Expertensystem muß unterschieden werden» ob der Infe- 
renzmechanismus des Expertensystems nach der Backward-Chaining- 
oder nach der Forward-Chaining-Technologie arbeitet. 

Bei der Transf ormat ion in ein Expertensystem mit Forward-Chai- 
ning (vgl. Abb.lb und Abb.2a) werden alle Regeln der Entschei- 
dungstabellen als Sachregeln in die Wissensbasis des Experten- 
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systems übertragen (vgl. Abb. 2a RI - R7 ). Das die Entschei- 
dungstabellen umgebene Kontrollwissen wird in Kontrollregeln 
umgewandelt (vgl. Abb.2a R8 - Rll). Hierbei handelt es sich um 
eine schlichte Überführung des Ablaufplans in Kontrollregeln. 

Die Transf ormation in ein Exper tertensystem mit Backward-Chai- 
ning (vgl. Abb.lb und Abb.2b) vollzieht sich in zwei Schritten: 
Zunächst wird das Sachwissen der Entscheidungstabellen Regel 
für Regel in die Wissensbasis des Expertensystems 
geschrieben(vgl. Abb.2b RI - R7 ). Als zweiter Schritt wird 
das Endekriterium des konventionellen Systems festgestellt und 
als Goal des Expertensystems deklariert. Danach werden die Be- 
dingungen gesucht, die dieses Goal erfüllen( Subgoals ). Aus 
dieser Bedingungs-Goal-Konstellat ion wird dann eine Regel der 
Wissensbasis generiert( Abb.2b R12 ). Iterativ werden dann die 
Bedingungen gesucht, die wiederum die Subgoals erfüllen (vgl. 
Abb.2b R8 - Rll). Die Bedingungen der Kont r ollregeln werden 
schließlich durch die Aktionen der Sachregeln erfüllt (vgl. 
Abb.2b R9, RIO). Auch Rekursion ist dadurch ausdrückbar (vgl. 
Abb.2b Rll ). Hierbei wird das Kon t r o llwissen weitgehend neu 
entwickelt, da ein Wechsel vom Forward-Chaining des konventio- 
nellen Programms zum Backward-Chaining vollzogen werden muß. 

3.1.2 Erfahrungen und Probleme bei einem praktischen Beispiel 

Erfahrungen wurden bei der Transformation des Filialanalysesy- 
stems von Entscheidungstabellen nach PC+ ( Inf erenzmechanismus 
arbeitet nach Backward-Chaining ) gesammelt. Dabei war diese 
Umwandlung problematisch und unnatürlich. Dies lag in erster 
Linie daran, daß viele zusammenhängende Datenwerte, viele reine 
Berechnungen und kein eindeutiges Ziel( Ziel ist: Benutzer 
wünscht Beendigung der Analyse ) Vorlagen. Diese Gründe bewir- 
ken, daß das Problem viel einfacher mit einem 
1 Forward-Algorithmus 1 bewältigt werden kann, aber durch die 
Verwendung des Shells in einen Backwa r d-Algor ithmus gezwängt 
werden mußte. 

3.2 Transformation von Expertensystemen in Entscheidunastabel- 
len 

3.2.1 Übertragung der Wissensbasis 

Da bei konventionellen Systemen mit Entscheidungstabellen ein 
strikter Pr ogr ammablauf vorhanden sein muß, ist es die erste 
Aufgabe bei der Transf ormation von Expertensystemen in Ent- 
scheidungstabellen diesen 'einen* strikten Programmablauf zu 
erkennen. Dies bedeutet, daß die Wissensbasis in Kontroll- und 
Sachwissen zu trennen ist und im Anschluß daran die Kontrollre- 
geln in einen Programmablauf p lan , die Sachregeln in 
Entscheidungstabellen umgewandelt werden müssen. 

Um die Trennung zwischen den Sachregeln und Kontrollregeln ein- 
deutig feststellen zu können, wird der Inferenzprozeß beobach- 
tet. Regeln, die die Prüfung anderer Regeln verursachen, gelten 
als Kontroll r egeln , Regeln, die keine Abarbeitung anderer Re- 
geln bewirken, gelten als Sachregeln. 
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Zusammengehörende Sachregeln werden in Regelgruppen zusammenge- 
faßt» jede Regelgruppe bildet dann eine Entscheidungstabelle 
(Regelgruppe 1 in Abb.2a bzw.2b bildet ET0001 in Abb.lb» Regel- 
gruppe 2 bildet ET0002 ). Der Entscheidungstabellengenerator 
vollzieht Vollständigkeits- » Widerspruchsf reiheits- und Redun- 
danzfreiheitsprüfung der Entscheidungstabellen» wobei 
gegebenenfalls sogar bei getesteten» laufenden Expertensystemen 
dadurch noch problematische Regeln zu finden sind. Abschließend 
werden bei Bedarf aufgrund der Entscheidungstabelleneigenschaf- 
ten Regelminimierungen vorgenommen» was letztendlich zu einem 
Laufzeitgewinn führt. 

Bei Expertensystemen mit Forward-Chaining-Technologie läßt sich 
das Kontrollwissen ebenfalls in einfacher Weise übertragen. 
Entsprechende Regeln werden direkt in den Programmcode übertra- 
gen und je nach Regelgruppe die passende Entscheidungstabelle 
angesteuert (vgl. Abb.2a und Abb.lb ). Es muß lediglich darauf 
geachtet werden» daß die übertragenen Regeln an der richtigen 
Stelle in den Programmablauf plan eingefügt werden. 

Die Übertragung der Kontrollregeln bei Backward-Chaining-Exper- 
tensystemen ist wesentlich schwieriger und bisher durch Heuri- 
stiken geprägt. Durch die Betrachtung des 
Ein-/Ausgabeverhaltens des Systems werden markante Zustände 
festgehalten. Diese Zustände werden dann als Meilensteine in- 
nerhalb des Programmablauf s betrachtet» so daß bereits durch 
die Betrachtung des Ein-/Ausgabeverhaltens eine Grobstruktur 
des sequentiellen Programmablaufs erstellt wird( z.B Prüfung 
einer Regelgruppe ist ein Meilenstein ). 

Im Anschluß daran wird festgestellt» was jeweils zwischen zwei 
solcher Meilensteine geschieht. Dabei werden zu allen Aktionen 
diejenigen Aktionen notiert» die unbedingt zuvor auszuführen 
sind. Zusätzlich wird der Inferenzprozeß beobachtet» indem jede 
Regel» die getestet oder angewendet wird» mitprotokolliert 
wird. Dadurch wird die Reihenfolge der Regelabarbeitung erkannt 
und die sequentielle Abarbeitung zwischen den Meilensteinen 
entwickelt. Einzelne Aktionen» die nicht in Entscheidungsta- 
bellen überführt sind» werden analog in den Programmablauf plan 
eingehängt . 

Die Übertragung der Kontrollregeln in den Programmablauf plan 
wird durch die Beobachtung weniger Programmläufe vollzogen. 
Daher muß gewährleistet sein» daß möglichst alle signifikanten 
Fälle in den Pr ogrammablauf plan nriteinbezogen wurden. 

3.2.2 Übertragung der Erklärungs- und Dialogkomponente 

Da die Erklärungs- und Dialogkomponente davon abhängt» wie das 
Expertensystem entwickelt worden ist» muß man hier wie folgt 
untersc heiden : 

Bei Expertensystemen » bei denen die beiden Komponenten explizit 
einen Teil der Wissensbasis darstellen» werden diese Komponen- 
ten bei der zuvor beschriebenen Transformation äquivalent mit- 
übertragen. 
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Dagegen bei Expertensystemen; die mit Shells entworfen wurden, 
die eine integrierte Erklärungs- und Dialogkomponente haben, 
müßten die beiden Komponenten nach der Transf ormation neu im- 
plementiert werden. Dies ist relativ aufwendig, da ein Teil 
dessen, was das Shell liefert neu codiert werden muß. 

Allerdings wird der Nutzer vom übertragenen konventionellen 
System i.a. keine Erklärungen erwarten, da man vornehmlich 
Batch-Systeme oder Routine-Systeme durch die Transf ormation 
beschleunigen will oder das übertragene System nur zu Verifika- 
tionszwecken erzeugt wird. Insofern kann zumindest auf die 
Übertragung der Erklärungskomponente verzichtet werden. 

3.2.3 Probleme bei einem praktischen Beispiel 

Bei der Transformation der mit Prolog implementierten Filial- 
analyse in ein konventionelles System mit Ent scheidungstabeilen 
mußte ein Wechsel vom Backward-Chaining zum Forward-Chaining 
durchgeführt werden. Dabei traten eigentlich keine nennenswer- 
ten Probleme auf. Diese Tatsache basiert sicherlich darauf, daß 
die Filialanalyse in Wahrheit immer den gleichen sequentiellen 
Ablauf hat. Dadurch wurde der Sequentialisierungsvorgang er- 
heblich vereinfacht. Aus diesem Grunde führte die oben 
beschriebene MethodeC Verdeutlichung der Reihenfolge der auszu- 
führenden Aktionen ) sofort zum Erfolg. 

Im allgemeinen ist aber die größte Schwierigkeit bei dieser 
Umwandlung, aus den vielen Regeln und dem Inf erenzmechanismus 
einen sequentiellen Ablauf zu erkennen. Um dies sinnvoll und 
mit möglichst geringem Zeitaufwand erreichen zu können, ist 
eine gute Dokumentation der Regeln und eine Beschreibung des 
Inf erenzprozeßes notwendig. 

3.2.5 Systematisierung der Transformation 

Die bisher beschriebene manuelle Tr ans f ormat i on basiert in er- 
ster Linie auf Heuristiken, die an den Beispielen gewonnen wur- 
den. Dies wiederum läßt noch viele Freiheiten in der Vorge- 
hensweise bei der Transf ormation von Expertensystemen in Ent- 
scheidungstabellen zu. Ziel sollte es sein, einen systemati- 
schen Weg für die Transformation zu finden. 

Dabei wird versucht, anhand von Beziehungen zwischen den Regeln 
des Expertensystems Cz . B . gleiche Parameter in der Prämisse oder 
Konklusion), eine allgemeine Methode zu finden, die die Zuord- 
nung von Sachregeln zu bestimmten Entscheidungstabellen 
bewirkte vgl. Sachregeln von Abb.2b mit Entscheidungstabellen 
von Abb . Ib ) . 

Die systematische Erkennung des Programmablauf plans erfolgt 
durch die Analyse verschiedener Programmläuf e , bei denen die 
Ein-/Ausgaben , die getesteten und angewandten Regeln mitproto- 
kolliert werden. Die Analyse erfolgt dabei durch eine Art Su- 
percompiler/8/, der aus mehreren Programmläufen unter Kontrolle 
des Inf er enzmechanismusses einen einheitlichen konventionellen 
Algorithmus erzeugen soll. 
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Bei der systematischen Transformation von mit PC+ entwickelten 
Expertensystemen wird ein Algorithmus verwendet» der basierend 
auf der Funktionsweise des Inf erenzmechanismus von PC+» der 
Beschreibung des Trace /!/ und mehrerer mitprotokollierter Pro- 
grammläufe ein konventionelles Programm mit Entscheidungstabel- 
len erzeugt /5/. 

3,3 Anwendungen 

In der Praxis ist eine Transf ormation von Entscheidungstabellen 
in Expertensysteme sinnvoll» wenn ein bestehendes konventionel- 
les System weiterentwickelt werden soll» und man bei den Fort- 
schreibungen und Ergänzungen die Vorteile der wissensbasierten 
Programmierung ausnutzen will. Damit sind dann die beachtlichen 
Investitionen in bestehende Entscheidungstabellensof tware be- 
wahrt und trotzdem Auf wärtskompatibilität gegeben. 

überdies ist eine solche Transf ormation auch bei der Neuerstel- 
lung von Programmen nützlich» nämlich als Schnittstelle während 
der Wissensakquisat ion . Wenn der Fachexperte oder Systemanaly- 
tiker bereit ist» das Problemwissen in Form von Entscheidungs- 
tabellen zu formulieren» so ist aufgrund der Transformations- 
möglichkeit für diese Problembereiche die Wissensakquisition 
beherrscht. Zudem ist das so gewonnene Wissen von besonderer 
Konsistenz» da es mit den für Entscheidungstabellen zu Verfü- 
gung stehenden Verifikationswerkzeugen geprüft werden kann. 

Eine Transf ormation von Expertensystemen nach Entscheidungsta- 
bellen bietet sich an, wenn ein wissensbasiertes System bereits 
vollständig entwickelt ist oder kaum noch Änderungen zu erwar- 
ten sind. Vorteile liegen in erster Linie im Laufzeitgewinn 
durch die .Entscheidungstabelleneigenschaften und die Möglich- 
keit, ein auf einem Spezialrechner entwickeltes Expertensystem 
auf vielen herkömmlichen Rechenanlagen verfügbar zu machen, 
bzw. in das vorhandene konventionelle EDV-System einer Unter- 
nehmung einzubetten. 

Während der Entwicklungsphase eines Systems bieten sich diese 
Transformationen dann an, wenn die Wissensbasis eines Experten- 
systems mit Hilfe von Entscheidungstabellen verifiziert werden 
soll. Nach der Verifikation erfolgt die Rücktransformation der 
Entscheidungstabellen in das Expertensystem , um die Weiterent- 
wicklung mit den Vorteilen der Wissensverarbeitung fortsetzen 
zu können. 

Die Festlegung von systematischen Wegen bei den Transformatio- 
nen wird einen erheblichen Fortschritt innerhalb der Software- 
Entwicklung bedeuten. 
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Kurzfassung: 

Die Entwicklung und Erprobung eines Expertetfsy stems auf dem 
Gebiet der Finanzberatung wird dargestellt. Das Wissensgebiet dieses 
Systems mit Namen LEBEX ist der Lebensversicherungssektor. Mit 
LEBEX wurde gezeigt, wie sich ein Expertensystem für diesen 
Anwendungsbereich auf einem Mikrocomputer realisieren läßt und 
wo noch Ansätze zur Verbesserung liegen. 

Schlüsselwörter: Expertensystem, Kundenberatung, 

Lebensversicherungen, Mikrocomputer. 



1. EINLEITUNG 

Während es schon einige Com puter Systeme mit umfassenden Daten 
zu Lebensversicherungen gibt, die dem Berater als Hilfsmittel dienen, 
ist die selbständige Beratung - sowohl über Lebensversicherungen 
als auch über allgemeine Geldangelegenheiten - noch weitestgehend 
Neuland für Computer. Zur Automatisierung der Finanzberatung 
kann die Technik der Expertensysteme einen hilfreichen Beitrag 
leisten. 

Es wird die Realisierung eines experimentellen Expertensystems zur 
Lebensversicherungsberatung beschrieben. LEBEX, der Name des 
Systems, steht für LEBensversicherungs-EXperte. Mit LEBEX wurden 
Erfahrungen in der Entwicklung und Erprobung eines solchen 
Systems gemacht. 

Begriffsbestimmung: Expertensysteme sind Programmsysteme, 
mit denen das Spezialwissen und die die Schlußfolgerungsfähigkeit 
qualifizierter Fachleute (Experten) auf zumeist recht eng begrenztem 
Fachgebiet nachgebildet werden sollen [4] ,[61 ,[131 - 

Finanzberatung ist die Beratung über alle die Finanzen 
betreffenden Fragen. 

Finanzen (Beratungsdomain) bezeichnen das Vermögen in Geld 
oder eine Vermögensanlage [51 ,[151 . 

Vermögen im Sinne des Privatrechts ist die Summe der 
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"geldwerten" Güter. 

Der Begriff der Beratung soll hier im Sinne einer Verkaufs- oder 
Kundenberatung verstanden werden. Die Motivation für den 
Berater ist häufig ein materielles Interesse. 

Zu den Branchen, in denen diese Art von Beratung durchgeführt 
wird, gehören Banken, Sparkassen, Hypothekenbanken, 
Bausparkasssen, Versicherungen und Steuerberater. 

Der Bereich der Lebensversicherungsberatung ist ein Teilgebiet 
der Finanzberatung. 

Lebensversicherungen betreffen hauptsächlich die Aspekte 

- Vermögenssicherung z.B. als Kapital-, Risiko- oder 

Rentenversicherung 

und 

- Vermögensaufbau z.B. in Form einer Ausnutzung des 

Vermögensbildungsgesetzes (Kapital-Police) und als eine 
Ausbildungs- oder Aussteuerversicherung. 

Motivation : 

Die Entscheidung, ein Expertensystem für diesen 
Anwendungsbereich zu bauen, hatte mehrere Gründe: 

* Der Lebensversicherungsbereich kann als ein in sich 
abgeschlossener Sektor der Finanzberatung die Grundlage einer 
eigenständigen Beratung bilden. 

* Eine Beratung über Lebensversicherungen ist komplex genug, um 
die Problematik einer allgemeinen Finanzberatung zu erfassen. 

* Ein Experte, der zur Zusammenarbeit bereit war, stand zur 
Verfügung. 

* Der Berater geht oft heuristisch vor. Zur Lösung der Aufgabe sind 
exakte mathematische Verfahren nicht angebracht. 

* Es gibt bisher nur dürftiges schriftliches Material über die 
Lebensversicherungsberatung, wobei die Betonung auf dem 
Vorgang der Beratung liegt, so daß eine systematische 
Beschäftigung damit und Aufzeichnung des Wissens durchaus 
lohnt. 

* Es gibt viele Berater auf diesem Gebiet, deren fachliche 
Kompetenz zumindest angezweifelt werden kann. Teilweise sind 
Berater auch eher reine Verkaufsleute für ihr Produkt als 
objektive Berater. Eine computerisierte Beratung könnte hier 
sicherlich Abhilfe schaffen. 

* Fehlentscheidungen im Lebensversicherungsbereich, die 
aufgrund mangelden oder falschen Wissens zustande kommen, 
sind üblicherweise schwer rückgängig zu machen und können zu 
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größeren finanziellen Einbußen führen. 

Bezüglich der Durchführung auf einem Mikrocomputer gilt 
insbesondere: 

* Die Aufgabe scheint nicht zu aufwendig, um auf einem 
Mikrocomputer implementiert zu werden. 

* Eine Anwendung im Außendienst ist aus Transport- und 
Kostengründen nur mit Hilfe eines Mikros vernünftig realisierbar. 
Hier bietet sich an, einem Finanzberater, der sich auf einem 
Spezialgebiet wie Lebensversicherungen weniger auskennt , mit 
einem Expertensystem auszuhelfen. 



2. WISSENSERWERB 

Für den Wissenserwerb stand ein Experte aus der 
Finanzberatungsbranche zur Verfügung. Dieser wird in Zukunft mit 
Berater bezeichnet. Innerhalb des Aufgabengebiets des Finanzberaters 
bot sich die Beratung über Lebensversicherungen als geeignete 
Anwendung an. 

Verschiedene Methoden wurden zur Wissensakquisition eingesetzt: 



a . Literaturstudium: Als Einstieg in das Wissensgebiet habe ich ein 

Buch der Verbraucherzentrale über Versicherungen und 
Informationsbroschüren verschiedener Gesellschaften durchgelesen. 
Ferner standen mir die Tarifwerke der in LEBEX verwendeten 
Lebensversicherungen und Werbebroschüren der 
Vermittlungsgesellschaft zur Verfügung. 

b. Interview: Für eine erste Strukturierung des Problembereichs 

wurde der Berater von mir befragt. Dabei wurden angesprochen: 
Klassifizierung der Kunden, übersieht über die in LEBEX zu 
verwendenden Lebensversicherungen, Phasen der Beratung und 
Vor-/Nachteile von bestimmten Lebensversicherungsformen. Der 
Berater hatte hier teilweise Schwierigkeiten, sein Wissen auf diesem 
etwas abstrakteren Niveau mitzuteilen. 

c. Protokoll- Analyse (Beratunesbeisoiele): Für den eigentlichen 
Beratungsvorgang war der Berater meine einzige Wissensquelle, da das 
entsprechende Wissen nur mündlich weitergegeben und daher nicht 
schriftlich fixiert ist. 
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Der Ablauf einer Beratung ließ sich am besten herausfinden, indem 
Beratungsbeispiele durchgesprochen wurden und daraus mit dem 
Berater Strukturmerkmale abgeleitet wurden. Dabei habe ich meist die 
Rolle eines Interessenten eingenommen, der beraten werden möchte. 
Diese Sitzungen wurden mit dem Kasettenrecorder aufgezeichnet und 
später ausgewertet. 

Zu Anfang der Sitzungen stand meist eine Wiederholung des von 
mir bereits aufgezeichneten Wissens. Diese ständige Überprüfung war 
notwendig, wie sich an den zahlreichen Korrekturen und 
Erweiterungen zeigte, die dabei zustande kamen. 

Die erste Phase der Zusammenarbeit mit dem Berater erstrekte sich 
über einen Zeitraum von 3 Monaten, in deren Verlauf wir 10 Sitzungen 
von 1 bis 2 Stunden Dauer hatten. 

d. Mitarbeiter Schulung: Ich habe einige Male an der 
Mitarbeiterschulung der Gesellschaft teilgenommen. Dieses war zwar 
für den Bereich der Lebensversicherungen weniger nützlich, brachte 
mir aber einige grundsätzliche Einblicke in das Gebiet der 
Finanzberatung. 

e. Beobachtung bei praktischer Arbeit: Fünf Mal war ich bei einer 
Kundenberatung anwesend. In drei Fällen kam dabei das Thema 
Lebensversicherungen zur Sprache. 



3. BERATUNG DURCH LEBEX 

Während des Interviews werden die zunächst wichtigen Daten 
des Benutzers aufgenommen, um das Benutzermodell zu bilden. Dieses 
Benutzermodell bildet die Basis für die spätere Beratung und 
berücksichtigt die folgenden Gesichtspunkte: 

1. persönliche Daten des Kunden (Name, Alter,...), 

2. berufliche Daten (Arbeitnehmer, selbständig, 

Einkommensgruppe,...) 

3. familiäre Informationen (Familienstand, Anzahl der Kinder,...), 

4. vorhandene Versorgungen (Lebensversicherungen, Rente: 

betrieblich, gesetzlich,...) 

5. Interessenschwerpunkte und Zukunftspläne (Bauabsichten,...). 



Im darauffolgenden Abschnitt, der Analyse, werden Hypothesen 
gebildet, die etwas über die Bedarfslage des Benutzers aussagen. 
Fragestellungen der folgenden Art werden dabei berücksichtigt: 
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Herrscht eine Unterversorgung der Familie? Ist die Rente genügend 
abgesichert? etc. Aufgrund der hier gewonnenen Ergebnisse wird ein 
übergeordneter Plan für die eigentliche Beratung erstellt. Dieser Plan 
gibt die potentiellen Beratungsthemen und eine vorläufige Reihenfolge 
für ihre Behandlung an. 




Abb.l: Struktur des Beratungssystems. 



Der Benutzer wird dann über die Themen beraten, die sich mit den 
vorher aufgestellten Hypothesen beschäftigen. Diese können sein: 

- Absicherung der Familie(AF), 

- Altersvorsorge(AV), 

- Hypothekenbeschaffung(HB), 

- Kapitalanlage^ A ), 

- Vorsorge für Berufsunfähigkeit(BU), 

- Ausbildung der Kinder(AK), 

- Aussteuervorsorge für Tochter(AT), 

- Vermögenswirksame Leistungen(VL). 
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Die Themenbehandlung erfüllt verschiedene Aufgaben: 

1. Informieren des Benutzers, 

2. Bestätigen bzw. Ablehnen der Hypothese, 

3. Detaillierung der Information über den Benutzer bzgl. der 
Themenstellung (wichtig für die spätere Auswahl eines 
Angebots). 

Einflußmöglichkeiten des Benutzers: Während der Behandlung 
eines Themas sind dem Benutzer verschiedene Möglichkeiten der 
Einflußnahme gestattet: 

- Er kann sich Abschnitte, die ihm noch unklar sind, wiederholen 

lassen. 

- Bei dieser Wiederholung kann er seine in diesem Teil gemachten 

Angaben geändert eingeben und damit den Beratungsverlauf 
ändern (benutzerinitiiertes Backtracking). 

- Er kann den Ablauf der Beratung beschleunigen und sich gleich 

ein Angebot vorlegen lassen, obwohl noch keine vollständige 
Beratung zu einem dazu passenden Thema erfolgt ist. 

- Er kann einen Wechsel zu einem anderen Thema bewirken. 

- Er kann bestimmte Daten ändern. 

Ein Thema ist vollständig behandelt, falls der Kunde die dazu 
notwendigen Informationen erhalten hat, er eventuelle technische 
Gegebenheiten verstanden und er positiv auf die Argumentation von 
LEBEX reagiert hat. Falls sich ein Thema nicht volständig behandeln 
läßt, wird das für den Benutzer nächstwichtigste Thema aufgegriffen. 
Beim Übergang zu einem neuen Thema werden vorhandene oder 
ermittelte Daten auf ihre Korrektheit überprüft und so weit wie 
möglich übernommen. Es werden die gleichen Informationen also 
nicht doppelt eingeholt. 

Wenn ein Thema vollständig behandelt ist, wird zum Angebotsteil 
übergegangen. Dort wird dem Benutzer unter Berücksichtigung seiner 
finanziellen Möglichkeiten und seiner Wünsche ein auf seine 
Bedürfnisse abgestimmtes Angebot über eine, eventuell auch mehrere, 
Lebensversicherungen vorgelegt. Der Benutzer kann zu diesem 
Angebot noch änderungswünsche angeben, die sich hauptsächlich auf 
Beiträge, Laufzeiten und Versicherungssummen beziehen. Auch an 
dieser Stelle ist noch ein Abbruch möglich mit Wechsel zu einem 
anderem Thema. Die Kundenwünsche werden dann bei einem 
erneuten Angebot berücksichtigt. Wenn der Kunde das Angebot 
akzeptiert, ist die Beratung beendet. 
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Grundlage für die Angebote bilden insgesamt 9 verschiedene 
Formen einer Lebensversicherung (Tarife). Jeder dieser Tarife kann 
für verschiedene Eintrittsalter, Laufzeiten, Summen etc. angeboten 
werden. Auch Kombinationen verschiedener Tarife sind erlaubt. 



4. WISSENSREPRÄSENTATION 

Zur Strukturierung des Wissens wurde ein Framekonzept 
implementiert, ähnlich dem, wie es in dem System CENTAUR von J. 
Aikins [11 verwendet wird. 

Bsp.: Modellierung der Tarife. 

Die Frames zu den Tarifen bilden einen großen Komplex. Sie 
modellieren Informationen zu verschiedenen Sachverhalten: 

- versicherungstechnische Werte (Beitrag, Summe, Laufzeit,...), 

- Bewertung der Eignung für verschiedene Kriterien (Absicherung 
der Familie, Kapitalanlage,...), 

- Dialog mit dem Kunden. 



Name 


Tarif 


Subframe 


Kapital-L.V., Rentenversicherung, Risiko-L.V., 




1+2, 1+4 


To-Create 


(Process-Rules) 




(Process-Slots) 


Rules: 




Reeel-1: Alter erößer-als 50 — > (Emofehle Laufzeit 12) Regel-2: Endalter 


ungleich (PLUS Alter Laufzeit) — > 


(OUT Text-Wid-EA-LZ) (ASK Laufzeit) (Setze Endalter) 


Slots: 




Mindestbeitrag: 


INTEGER, default: 10 DM 


Mindestsumme: 


INTEGER, default: 5000 DM 


Mindesteintrittsalter: INTEGER, default: 15 Jahre 


Eintrittsalter: 


default: Alter FROM Kunde 


Laufzeit: 


INTEGER, default:: 25, IF-NEEDED — Ask-User 


Gewinnanteile: 


IF-NEEDED — > (GA Laufzeit) 


Versicherungssumme 


INTEGER>=Mindestsumme, default: FROM 




Tarifwahl, IF-NEEDED — > Ask-User 


Merkmale: 




AF-Wert 


( 1,2, 3,4,5 Mhervorragend-geeignet, 


AV-Wert 


empfehlenswert, befriedigend, 


HB-Wert 


weniger-geeignet, ungeeignet ) 


KA-Wert 




BU-Wert 




AK-Wert 




VL-Wert 





Abb.2: Tarif-Frame 




Der hierarchisch höchste dieser Frames ist der Tarif-Frame 
(Abb.2). Hier werden Slots angegeben und teilweise schon mit Werten 
initialisiert, die auch für alle anderen Frames zu Tarifen Gültigkeit 
haben und von diesen zur Instantiierung übernommen werden. 

Der Tarif 2 -Frame (Abb.3) gibt die Funktionen an, die den Beitrag 
und die Versicherungssumme dieses Tarifs berechnen. Es stehen 
diesem Frame die Inhalte der übergeordneten Frames Kapital-L.V. 
und Tarif zur Verfügung. Die Einträge der Slots Leistungen und 
Kurzbeschreibung enthalten Referenzen auf Textbausteine, die die 
Leistungen, die dieser Tarif für einen Kunden erbringt, in 
ausführlicher bzw. in knapper Form beschreiben. Bei einer 
Zusammenfassung der alternativen Angebote kann auf diese Einträge 
Bezug genommen werden. 



Name 

Kommentar 



Superframe 

Rules; 

Regel- 1; nicht Beitrag und nicht Versicherungssumme — > 

Ask-User Beitrag 

Regel-2: ... 

Slots: 

Beitrag: (Tarif2 Alter Summe Laufzeit) 

Versicherungssumme: (Tarif2 Alter Beitrag Laufzeit) Auszahlungsbetrag: 
(Versicherungssumme * (1 + Gewinnanteile)) 

AF-Wert: 2 
AV-Wert: 1 
HB-Wert: 3 
KA-Wert: 2 
BU-Wert: 5 
AK- Wert: 5 
VL-Wert: 4 

Leistungen: Textl 

Kurzbeschreibung: Text4 

Dialog: (Process-Dialog) 

SYS 1 : Text 1 .Question 1 
US 1.1 : STOP 

.2 : (Tarif2), SYS2 
.3 : Text2.lNF4.SYS2 
.4 : STOP 
.5 : Text35YS2 
SYS2 : Text4,Question2 
US2.1 : STOP 

.2 : Text5.(Tarif2).SYS2 
.3 : Text6 ,(T arif 2 ),SYS2 
.4 : STOP 



Tarif 2 

Gemischte Versicherung auf den Todes- und 
Erlebensfall mit 100 Proz. Auszahlung im 
Todesfall und 100 Proz. zuzüglich 
Gewinnanteile im Erlebensfall 
Kapital-L.V. 



Abb.3: Tarif2-Frame 
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Der Eintrag des Slots Dialog regelt, nachdem technischen Details 
geklärt sind, wie dem Kunden ein Angebot zu diesem Tarif zu 
unterbreiten ist. Die SYSi sind Systemaktionen. Die USi.j bezeichnen 
Bedingungen für Aktionen von LEBEX. Diese Bedingungen spezifizieren 
meistens die Antwortmöglichkeiten des Benutzers auf ein von LEBEX 
vorgelegtes Menü. Die zu Beginn des Dialogparts aufgerufene 
LISP-Funktion Process-Dialog ist gleich für alle Frames, in denen 
Dialoge modelliert werden. 

Textbausteine bestehen aus Abschnitten der von dem Berater im 
Laufe einer Beratung gemachten äußerungen und Skizzen. Diese Texte 
können Parameter, LISP- Ausdrücke und Steuerzeichen enthalten. 
LEBEX enthält 194 Textbausteine. 

Die Wertetabellen der in LEBEX verwendeten Tarife wurden mit 
Hilfe von Regressionsverfahren in kompakte Tarif-Funktionen 
verwandelt. Dadurch wurde Speicherplatz eingespart und das 
Abtippen der Tabellen umgangen. Für jeden in einem Tarif zu 
bestimmenden Wert wurden mehrere Funktionen ausgerechnet, die 
sich jeweils in der Anzahl und der Art ihrer Glieder unterscheiden. 
Eine zufriedenstellende Kombination wurde meist in wenigen 
Durchgängen gefunden. Die Berechnung des Beitrags des Tarif2 wird 
zum Beispiel von folgender Funktion realisiert: 

BEITRAG - (CI ‘ALTER + C2*LAUFZEIT + C3*ALTER*LAUFZEIT + 
C4* ALTER 2 + C5*LAUFZEIT 2 + C6*ALTER 2 *LAUFZEIT + 
C7*ALTER*LAUFZEIT 2 + C8) » ((SUMME*C9) / 1200 ) 

Die Ci sind Konstanten mit 8-stelliger Genauigkeit. 

Die Aufgaben der insgesamt 130 Regeln sind 

- Auswertung von Kriterien, 

- Datenüberprüfung, 

- Kontrolle der Dialogführung. 

a. Auswertung 

Informationen, die LEBEX vom Kunden erhält, werden mit Hilfe von 
Regeln ausgewertet. Die Aktionsseite der Regeln liefert dazu eine 
Bewertung von Kriterien, die etwas über die Eignung bestimmter 
Beratungsthemen aussagen. Die daraus resultierende 
Gesamtbewertung wird zur Planung der Beratung herangezogen. 

Bsp.: Berufstätig und nicht- selb ständig und nicht- vermögenswirk- 

same-Leistungen und Einkommensgrenze-unterhalb 

— > Ausnutzung-des-4.VBG-sehr-empfehlenswert. 
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b. Datenüberprüfune 

Ein weiterer Einsatz der Regeln liegt in der Überprüfung von Daten. 
In diesem Zusammenhang wird auch die Korrektheit und Konsistenz 
von Daten überprüft. Angaben eines Kunden, die im Widerspruch zu 
bereits ermittelten Werten stehen, sollen erkannt und gegebenenfalls 
berichtigt werden. 

c. Dialogführung 

Die Dialoge sind insbesondere bei der Themenbehandlung von 
Bedeutung. Das Wechselspiel System-Benutzer wird mit Hilfe einer 
Regeldarstellung modelliert. Jeweils eine Frage-Antwort 
(Aktion-Reaktion) Situation wird dabei von einem Regelpaket 
kontrolliert. 

Je ein Regelpaket zur Dialogführung besteht aus drei Teilen: 

- Der TEST -Part enthält Regeln zur Überprüfung, Initialisierung und 

Ermittlung von Daten. 

- Im TEXT-Partwird ein Text auf dem Bildschirm ausgegeben und 
die Reaktion des Benutzers eingelesen. 

- Der ANSWER-Part arbeitet die Reaktion des Benutzers ab. 

In einem Paket müssen nicht alle Teile vorliegen. Die Pakete 
umfassen gewöhnlich 5 bis 10 Regeln. 

Die zu einem Themenkomplex gehörenden Regeln bilden jeweils die 
Regelbasis (Agenda), auf der der Interpreter arbeitet. Jedes Thema 
kann so als in sich abgeschlossen und funktionsfähig betrachtet 
werden. Dieser modulare Aufbau ist für die Entwicklung und 
Erweiterung von LEBEX von Vorteil. 

Wissensverarbeitung 

Die unterschiedlichen Wissenstypen in LEBEX werden jeweils von 
einem eigenen Prozessor bearbeitet: 

- Prozeduren, die in LISP kodiert sind, werden vom 
LISP-Interpreter abgearbeitet. 

- Die Regeln werden dem Regelinterpreter übergeben. 

- Frames werden von einer weiteren Prozedur behandelt. 

Ein Produktionssystem, bestehend aus der Wissensbasis und der 
Inferenzkomponente (Interpreter), bildet den Kern von LEBEX. 

Der Interpreter kontrolliert die Ausführung der Regeln. Er 
arbeitet jeweils auf einer Teilmenge (Agenda) der Regeln, die für das 
jeweils zu behandelnde Thema relevant sind. Der zugrundeliegende 
Interpreterzyklus [10, p. 21] arbeitet vorwärtsverkettend. Falls 
mehrere Regeln anwendbar sind (Konflikt), wird die Regel mit der 
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höchsten Priorität ausgewählt (Konfliktauflösung), die sich aus einer 
auf den Regeln des Systems definierten Ordnung ergibt. 



5. IMPLEMENTATION 

Die Implementationsarbeiten wurden auf dem TRS80, ModelHI, 
von Tandy, durchgeführt. Das System wurde in der Sprache muLISP 
programmiert. 

Die Konfiguration besteht aus einem Basisteil und einem 
Beratungsteil. 

Das Basisteil enthält: 

- der Kontrollzyklus von LEBEX, 

- der Prozessor zur Frameverarbeitung, 

- der Regelinterpreter, 

- eine Datei über aktuelle Kundendaten, 

- Funktionen zur Verwaltung der Module und Zusammenstellung 
der für einen Beratungsabschnitt erforderlichen Komponenten, 

- Ein-/Ausgabefunktionen. 

In den verbleibenden Speicherplatz wird der Beratungsteil, das für 
einen Beratungsabschnitt relevante Wissen (Regeln, Textbausteine, 
Tariffunktionen etc. ), untergebracht. 

LEBEX hat weniger umfangreiche Komponenten und noch eine 
bescheidene Wissensbasis. Ein komplettes und ausgefeiltes 
Expertensystem, das vieleicht sogar über mehrere Produkte aus dem 
Finanzbereich berät, würde sich mit der Kapazität eines Standard- 
PCs (640Kbytes RAM) bewältigen lassen. Die Problematik und die 
Ergebnisse, die in Zusammenhang mit der Arbeit an LEBEX entstanden 
sind, lassen sich daher übertragen auf die Situation eines 
entsprechend größeren Systems auf einem größeren Mikrocomputer. 
Dieser Bottom-Up-Ansatz ist außerdem gut dazu geeignet, die 
minimale Hardwarekonfiguration (kostengünstig) eines kompletten 
Systems zu finden. 



6. EVALUATION 

Zur Evaluation wurde LEBEX in einen möglichst reale 
Anwendungssituation gestellt, um seine Performance zu bewerten 
und Hinweise zur Verbesserung zu erhalten. 
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Benutzer von LEBEX sind also nicht mehr der Systementwickler 
oder der Domainexperte (Berater), sondern Personen, die an der 
Entwicklung nicht beteiligt waren. Dieser Benutzer braucht über 
keinerlei EDV- oder Lebensversicherungskenntnisse zu verfügen, kann 
also jede beliebige Person sein, für die man auch sonst eine 
Lebensversicherungsberatung durchführen würde. 

Ein wichtiger Aspekt dieser Phase war die Untersuchung der 
Akzeptanz und der Benutzerfreundlichkeit von LEBEX. Der typische 
Benutzer wird LEBEX wahrscheinlich nur einmal, höchstens aber zwei- 
oder dreimal, konsultieren. Es müssen daher besonders hohe 
Anforderungen an die Handhabbarkeit des Systems gestellt werden. 
Denn von einem Benutzer kann nicht verlangt werden, daß er sich für 
eine einzige Sitzung vorbereiten soll (z.B. Studium eines Manuals, 
längere Anweisungen). 

Die Evaluation von LEBEX erfolgte in drei Richtungen: 

1. Beobachtung des Kundenverhaltens während einer 
Konsultationssitzung 

2. Auswertung eines Fragebogens, den der Benutzer im Anschluß 
an die Konsultation ausgefüllt hat. 

3. Vergleich mit dem menschlichen Berater. 



Benutzerbeobachtung 

Der Benutzer erhielt vor seiner Sitzung mit LEBEX lediglich die 
Information, daß es sich um eine Lebensversicherungsberatung 
handelt und daß die Tastatur des Computers wie eine 
Schreibmaschine zu benutzen sei und er seine Eingaben mit ENTER 
abzuschließen habe. 

Ein paar Anregungen für Verbesserungen, die ich durch die 
Beobachtung der Benutzer erhielt: 

* An Stellen, wo dem Benutzer viel Information auf einmal (z.B. 
eine volle Bildschirmseite) geliefert wurde, reagierte dieser 
häufig erschrocken oder abweisend. Abhilfe schuf die Zerlegung 
der Ausgabe in mehrere kleine Einheiten, wobei zwischendurch 
immer wieder die Reaktion des Benutzers erforderlich wird. 

* Bei einigen Benutzern tauchten Fragen zu den gleichen Absätzen 
oder Formulierungen auf. Der entsprechende Absatz wurde neu 
formuliert oder es wird dem Benutzer bei Bedarf 
Zusatzinformation dazu geliefert. 

* Einige Benutzer wünschten nach Beratungsende, die von LEBEX 
gemachten Angebote noch einmal im überblick präsentiert zu 
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bekommen. Dies ließe sich natürlich bewerkstelligen. Falls jedoch 
zu viele Angebote Vorgelegen haben, sollte sich der überblick auf 
einige wenige beschränken. Zu deren Auswahl könnten Regeln 
angegeben werden. 

* Bei längeren Sitzungen (über 20 Minuten) konnte ich teilweise 
einen Konzentrationsabfall beim Benutzer beobachten. 

Abhilfe ist durch eine interessantere Gestaltung des 
Beratungsverlaufs möglich. Bei komfortableren Geräten könnte 
man dazu von Farbgraphiken oder Sprachausgabe (Vorlesen der 
Systemausgaben) Gebrauch machen. 

* Frage des Benutzers: "Was wäre passiert, wenn ich mich an jener 
Stelle (eben) anders entschieden hätte ?" Es wird an den 
entsprechenden Verzweigungspunkt zurückgekehrt, um dort 
einen alternativen Weg einzuschlagen. 



Fragebogenaktion 

Insgesamt haben 34 Personen im Alter von 20 bis 58 Jahren mit 
unterschiedlichen Berufen an der Befragung teilgenommen. Die 
Aussagen dieser Personenzahl sind sicherlich nicht repräsentativ. 
Trotzdem erhielt ich dadurch einige Hinweise über die Akzeptanz von 
LEBEX. Gut ein Drittel der Teilnehmer hatte Computererfahrung. 79 
Prozent der Teilnehmer hat die Beratung gefallen. Unter denjenigen, 
denen diese Beratung nicht zusagte, haben nach meiner Ansicht viele 
eine generelle Abneigung gegen Beratungen dieser Art. Kaum einer 
empfand die Dauer der Beratung als zu lang. Diese Form der Beratung 
scheint also nicht zu langweilen. Ein weiteres wichtiges 
Akzeptanzkriterium, das LEBEX erfüllte, war, daß für keinen die 
Beratung unverständlich war. Die Handhabbarkeit des Systems scheint 
ebenfalls ausreichend zu sein, da kein Benutzer angab, 
Schwierigkeiten mit der Bedienung zu haben. Ein Drittel der 
Teilnehmer wünschte sich, von LEBEX besser informiert zu werden. 
Bei der Frage, ob Beratung durch Mensch oder Computer waren fast 
drei Viertel auf Seiten des Menschen. Immerhin zogen 15 Prozent die 
Beratung durch den Computer vor. Einige der Gründe, die für die 
Präferenz eines menschlichen Beraters genannt wurden: 
Zwischenfragen sind möglich; es kann individueller gefragt werden; 
Hemmungen, von einer Maschine ausgefragt zu werden. 

Vergleich mit dem menschlichen Experten 

Der Berater ist flexibler im Umgang mit seinen Klienten. Er kann 
sich besser auf den Klienten einstellen als das ein Computer könnte. 
Ein guter Berater erkennt, wann ein Klient Verständnisschwierigkeiten 
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hat und kann sofort darauf eingehen. Auch spürt er Desinteresse oder 
gar Abneigung des Klienten. Ein versierter Berater versteht es, sich zu 
Anfang einer Beratung eine Vertrauensbasis aufzubauen. Bei 
gefühlsmäßig motivierten Entscheidungen wird meist die Beratung 
durch den menschlichen Berater bevorzugt. 

Die Komplexität des menschlichen Entscheidungsvorgangs, bei dem 
häufig noch emotionale Aspekte mitspielen, läßt sich nicht mit einem 
Expertensystem erfassen. Besondere Schwierigkeiten entstehen dort, 
wo ein fließender Übergang vom Beratungswissen zum Alltagswissen 
besteht. 

LEBEX ist dem Menschen dort überlegen, wo es darauf ankommt, 
eine größere Menge von (rechentechnischen) Daten zu überblicken 
und zu Gunsten des Klienten auszuwerten. Bei LEBEX gilt dies für die 
Analyse des Kundenbedarfs, für die Überprüfung von 
Versorgungslücken und das Ausarbeiten eines maßgeschneiderten 
Angebots. 



7. ZUSAMMENFASSUNG UND AUSBLICK 

Die Lebensversicherungs-Beratung als Domain für ein 
Expertensystem ist hinreichend motiviert. Mit LEBEX wurde gezeigt, 
daß 

- ein Expertensystem ein adäquates Mittel zur Modellierung eines 

Finanzberatungssystems ist und 

- sich ein solches System auf einem Mikrocomputer realisieren läßt. 

LEBEX wurde in LISP implementiert. Die Wissensbasis ist durch 
Frames strukturiert. Wesentliche Wissenseinheiten sind durch Regeln 
repräsentiert. Das zugrundeliegende Produktionssystem arbeitet 
vorwärtsverkettend mit Möglichkeiten zum Backtracking. 

LEBEX führt eine eigenständige Beratung des Benutzers durch, der 
über keinerlei EDV- oder Lebensversicherungsvorkenntnisse verfügen 
muß. Die Benutzer bewerten die Beratung mit großer Mehrheit positiv. 
Es zeigte sich aber auch, daß mit einem Expertensystem nicht das 
Niveau eines zwischenmenschlichen Beratungsdialogs erreicht werden 
kann. Insgesamt ist ein versierter Berater einem Expertensystem noch 
überlegen, besonders, wenn er es versteht, seine Menschenkenntnis 
und sein Allgemeinwissen effizient in die Beratung einzubringen. 
Gegenüber weniger guten Beratern wird ein Expertensystem jedoch 
meist leistungsfähiger sein. 

Beim derzeitigen Stand der Kunst empfehle ich eine kombinierte 
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Beratung von Mensch und Maschine. Beide können sich ergänzen, 
indem Erhebung und Auswertung der Daten und Angebotsausarbeitung 
von einem Expertensystem übernommnen werden. Das eigentliche 
Gespräch bleibt dabei die Aufgabe des Beraters. 

Für eine Verbesserung der Leistung von LEBEX ist erforderlich: 

(a) quantitativ: Vergrößerung der Wissensbasis (evtl, für mehrere 
Finanzprodukte) 

Dazu muß überprüft werden, inwieweit bestehende 
Finanzdatenbanken , Börseninformationen, etc. als 
Wissensquellen genutzt werden können. 

(b) qualitativ: Integration von Allgemeinwissen (common-sense) 

Es muß zunächst eine genaue Untersuchung der 
Common-sense-Bestandteile erfolgen, die in eine Beratung 
eingehen. 
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NETCON 

Ein Expertensystem zur Konfigurierung von lokalen Netzen 
auf der Basis des Bürosystems 5800 



D. Lehmann, <3. Normann, G. Schramm, Siemens AG München 



Zusammenfassung: NETCON ist ein Expertensystem zur Konfigurierung von lokalen 
Netzen auf der Basis des Bürosystems 5800. Es werden die Ausprägungen aller im Netz enthaltenen 
Arbeitsplatzstationen in Soft- und Hardware festgelegt, die dabei benötigten zentralen Dienste 
automatisch ermittelt und auf entsprechende Geräte verteilt, sowie die Netztopologie selbst be- 
stimmt Diese funktionale Aufteilung wird bereits durch die Konzeption von NETCON berück- 
sichtigt. Im Rahmen dieses Papiers werden sowohl die Architektur des Systems, einige Realisierungs- 
aspekte, sowie Erfahrungen ; die während der Projektdurchführung gemacht wurden, vorgestellt. 



1 Motivation 

Das Bürosystem 5800 der Firma Siemens ist ein verteiltes System für Do- 
kumentenbearbeitung und Informationsmanagement im Büro. Es ermöglicht den 
angeschlossenen Arbeitsplatzstationen die Kommunikation untereinander sowie 
die Nutzung zentraler Dienste und Einrichtungen. Die einzelnen Arbeitsplatzsta- 
tionen und die zentralen Systemkomponenten sind miteinander über ein Busnetz 
(Ethernet) verbunden. 

Bisher werden alle Netze des Bürosystems 5800 per Hand von den 
einzelnen Vertriebsbeauftragten konfiguriert. Dabei ist eine Vielzahl von Zusam- 
menhängen zwischen den einzelnen Systembausteinen zu berücksichtigen. Des- 
halb ist es derzeit nur mit großem Aufwand möglich, eine in sich konsistente und 
den jeweiligen Bedürfnissen optimal angepaßte Konfiguration zu erstellen. 

In Zukunft soll diese Tätigkeit durch ein Expertensystem unterstützt 
werden, das alle in solchen Netzen bestehenden Abhängigkeiten berücksichtigt 
und damit die technische Korrektheit für jede durchgeführte Konfigurierung ge- 
währleistet. Das spart nicht nur Zeit und Geld, sondern führt außerdem zu qualita- 
tiv gleichbleibend hohen, objektiven Lösungen. 
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Aus dieser Aufgabenstellung heraus ergibt sich der Name des Systems: 

NETCON - ein System, um lokale Netze zu konfigurieren. 

Dieses Papier beschreibt die Funktionalität, sowie die wesentlichsten Ar- 
chitekturmerkmale des Expertensystems NETCON. Zudem werden Erfahrungen ge- 
schildert, die während der Projektdurchführung gemacht wurden. 

2 Aufgabenstellung 

Das Expertensystem NETCON unterstützt die Erst-Konfigurierung sowie 
den weiteren Ausbau von lokalen Netzen auf der Basis des Bürosystems 5800. Ein 
derartiges lokales Netz ist in Bild 1 schematisch dargestellt. 



Arbeitsplatzstationen (APS) 




Bild 1 : Beispiel eines lokalen Netzes 
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Bei der Konfigurierung eines lokalen Netzes gilt es daher, 

- die Anzahl und die Ausprägung der einzelnen Arbeitsplatzstationen (APS), 

- Art und Umfang der zentralen Dienste und zentralen Rechner (Server) sowie 

- die einzelnen Netsbausteine (Kabelsegmente, Anschlüsse, etc.) zu bestimmen. 

Beim ersten Punkt muß berücksichtigt werden, wieviele Benutzer sich 
einen Arbeitsplatz teilen und welche Tätigkeiten diese verrichten (Sekretärin/Sach- 
bearbeiter). Für jeden Arbeitsplatz ist somit die Software- und Hardwareausprä- 
gung exakt zu bestimmen. Dabei ist zu beachten, daß sowohl verschiedene Soft- 
ware-Pakete aufeinander aufbauen, als auch Abhängigkeiten zwischen Hard- und 
Software bestehen (z.B. lokaler Drucker benötigt zugehörigen "Drucker-Treiber"). 

Bei den zentralen Diensten (Drucker, Ablage, Electronic Mail) muß 
zunächst bestimmt werden, welche Dienste in welchem Umfang im Netz verfügbar 
sein sollen. Danach gilt es, diese nach unterschiedlichen Optimierungskriterien wie 
z.B. Preis, Leistung oder Betriebssicherheit auf entsprechende Server zu verteilen. 

Die Netztopologie spielt eine wesentliche Rolle bei der Installation eines 
Netzes. Sie umfaßt die einzelnen Kabelsegmente, deren Länge sowie Anordnung. 
Von besonderer Bedeutung ist die Verteilung "kritischer" Dienste (zentrale Adreß- 
und Benutzerverwaltung) innerhalb des Netzes. Sie sollten so verteilt sein, daß 
durch Ausfall eines Segmentes die Gesamtfunktionalität des Netzes möglichst 
wenig gestört wird. 

Anwender des Expertensystems NETCON sind in erster Linie Vertriebsbe- 
auftragte und Fachberater. Sie können dem Kunden damit bereits frühzeitig kon- 
sistente und optimale Konfigurierungsvorschläge unterbreiten. Zusätzlich gene- 
riert NETCON wichtige Informationen für das Wartungs- und Bedienpersonal. 

Das Expertensystem NETCON übernimmt folgende Aufgaben : 

- die Neukonfigurierung eines Netzes sowie 

- die Modifikation bzw. Erweiterung bestehender Netze. 

Für die unterschiedlichen Anwender bzw. Aufgabengebiete werden je- 
weils spezifische Ausgaben generiert: 

- Angebote bzw. Bestellten für die Vertriebsbeauftragten/Fachberater 

- Installationshinweise für Wartungs- und Bedienpersonal 

- graphische Darstellungen der Netztopologie. 
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Das Format der Ausgaben wird so gewählt, daß die entstehenden Doku- 
mente mit dem Bürosystems 5800 weiter bearbeitet werden können. 

Ein Überblick über die Anwendungsmöglichkeiten von NETCON ist in 
folgendem Bild dargestellt: 




Bild 2: Aufgabengebiete des Expertensystems NETCON 

Da sowohl neue Netze konfiguriert als auch bestehende erweitert wer- 
den sollen, muß bei den einzelnen Komponenten eines Netzes unterschieden wer- 
den, ob sie bereits installiert oder nur projektiert sind. Zur Auswertung werden 
jeweils nur die neu projektierten Systemteile berücksichtigt. 

Ziel bei der Anwendung von NETCON ist es, in Interaktion mit dem 
Benutzereine "optimale" Konfiguration zu erstellen. Darunter verstehen wir eine 
ablauffähige, vom Funktionsumfang ausreichende und trotzdem kostengünstige 
Lösung. 
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Realisierung als Expertensystem 

Für die Konfigurierung eines lokalen Netzes gibt es keinen fest vorge- 
gebenen Algorithmus zur Problemlösung. Es gibt aber viele Zusammenhänge, die 
beim Vorgang des Konfigurierens zu berücksichtigen sind. Diese Abhängigkeiten 
sind nur zum Teil in Form von Fakten und Vorschriften gegeben; sehr oft ergeben 
sie sich aus individuellen Erfahrungen einzelner Konfigurierer (heuristisches Wis- 
sen). 



Die Darstellung von vagem Wissen ist bei Expertensystemen viel leichter 
möglich als in der herkömmlichen Programmmierung. Daher ist es sinnvoll, das 
System NETCON als Expertensystem zu realisieren. Die dabei gegebene strikte Tren- 
nung von Inferenzmechanismus und Wissensbasis führt außerdem zu einem 
äußerst flexiblen System. Bei Einführung neuer Hard- bzw. Software oder Modifi- 
kation bestehender Komponenten braucht nur die Wissensbasis ergänzt bzw. ge- 
ändert zu werden. 

Zur Realisierung von NETCON wird die für Expertensysteme charakteristi- 
sche Entwurfsmethode, das Rapid Prototyping, eingesetzt. 



Entwicklungsumgebung 

Für das Expertensystem NETCON soll die Entwicklungs- mit der Ablauf- 
umgebung identisch sein, um eventuelle Probleme bei einer späteren Portierung 
auszuschließen. Entwickelt wird auf der Hardware des Bürosystems 5800. Auf 
diesem System steht mit der Programmiersprache Interlisp-D® [1] und der Anwen- 
dung LOOPS® [2] (Lisp based Object Oriented Programming System) eine mächtige 
Entwicklungsumgebung zur Verfügung. LOOPS ist eine hybride Entwicklungsum- 
gebung; der Entwickler wird nicht auf eine Form der Wissensrepräsentation festge- 
legt, sondern kann zwischen verschiedenen Formalismen wählen und sie miteinan- 
derverknüpfen. 

Ziel bei der Realisierung eines Expertensystems ist es, das Wissen in einer 
möglichst "natürlichen" Form darzustellen. Darunter verstehen wir in diesem Zu- 
sammenhang die für den Menschen am leichtesten verständliche Form. Daher fin- 
den die von LOOPS unterstützten Wissensrepräsentationsformen in NETCON Ver- 
wendung; allerdings in verschiedenen Teilgebieten und in unterschiedlichem Um- 
fang. 



t Interlisp-D® und LOOPS® sind Trademarks der Xerox Corporation 
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3 Architektur von NETCON 

NETCON liegt auf oberster Abstraktionsstufe der objektorientierte Ent- 
wurf zu Grunde. Die Komponenten des Systems werden als Objekte definiert, die 
über einen genau definierten Funktionsumfang verfügen. Wie die einzelnen Ob- 
jekte (Komponenten) die ihnen zugeordneten Aufgaben realisieren, soll unter Aus- 
nutzung der den Problemstellungen angemessenen Programmiermethoden erfol- 
gen. Alle Programmiermethoden und -stile werden dadurch der objektorientierten 
Programmierung untergeordnet. 

Zerlegung in Komponenten 

Das Expertensystem NETCON wird in folgende Komponenten zerlegt: 

- Konfigurierer zur Durchführung der eigentlichen Aufgabenstellung, ein Netz 

zu konfigurieren; stellt den Inferenzmechanismus des Systems 
dar, der auf der Wissensbasis operiert. 

- Wissensbasis enthält das dem System zu Grunde liegende Wissen in Form von 

Fakten und Regeln, deren konkrete Repräsentation später 
beschrieben wird. 

- Konfiguration abstrakte, interne Repräsentation eines aktuellen Netzes, die 

vom Konfigurierer unter Zuhilfenahme der Wissensbasis erstellt 
wird. 

- Auswerter zur Generierung der verschiedenen Ausgaben des Systems nach 

unterschiedlichen Gesichtspunkten. 

- Regeleditor zur Erweiterung und Modifikation der Wissensbasis; stellt die 

Wissenserwerbskomponente des Systems dar. 

- Erklärer zur Erläuterung der einzelnen Schritte während des Problem- 

lösungsprozesses. 

- Administrator zur Realisierung verschiedener Verwaltungs- und Archivier- 

funktionen. 

- Dialogmanager zur einheitlichen Behandlung aller Ein-/Ausgaben. 

Der Konfigurierer stellt zusammen mit der Wissensbasis den Kern von 
NETCON dar. Die restlichen Komponenten dienen der funktionalen Abrundung des 
Systems (Bild 3). 
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Bild 3: Komponenten von NETCON 



Konfigurierung 

Analog zur Vorgehensweise des menschlichen Experten geschieht auch 
die Konfigurierung durch NETCON in drei Teilen (Bild 4): als erstes wird die Anzahl 
und der Ausbau der einzelnen Arbeitsplatzstationen bestimmt (APSCON). Daran 
anschließend werden die zentralen Dienste ermittelt und auf entsprechende 
Server-Hardware verteilt (SERCON), bevor im dritten Abschnitt die Neztbausteine 
ermittelt, die Netztopologie bestimmt und die einzelnen Komponenten ans Netz 
angeschlossen werden (ETHCON). Durch diese Aufteilung in Teil-Konfigurierer wird 
das Problem in logisch zusammengehörige und überschaubare Einheiten zerlegt, 
was sich auch in der Struktur der Wissensbasis fortsetzt. 

Die einzelnen Teil-Konfigurierer stellen in sich abgeschlossene Systeme 
dar; sie können sich nicht gegenseitig aufrufen. Wollen sie miteinander kommuni- 
zieren, so hinterlegen sie ihre Funktionswünsche auf einem "schwarzen Brett" 
(blackboard), das dann von dem entsprechenden anderen Teil-Konfigurierern aus- 
gewertet wird. 

Bei der Konfigurierung der einzelnen Arbeitsplatzstationen ist zu be- 
rücksichtigen, daß drei verschiedene Betriebsmodi unterschieden werden (netzin- 
tegriert, abgesetzt und "stand alone"); die jeweils angebotene Software ist ab- 
hängig vom gewählten Betriebsmodus (z.B. sind Emulationen nur auf netzinte- 
grierten Arbeitsplätzen möglich). Die Auswahl bestimmter SW-Pakete für Arbeits- 
plätze hat Auswirkungen auf die Server-Konfigurierung, da die dazu benötigten 
zentralen Dienste innerhalb des Netzes verfügbar sein müssen. Die Anforderungen 
an die Server werden auf dem Blackboard hinterlegt, um sie später mit der Kompo- 
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Bild 4: Aufteilung des Konfigurieren 



nente SERCON auszuwerten. Neben der Festlegung der SW-Eigenschaften für jede 
Arbeitsplatzstation wird auch deren Hardware-Ausprägung bestimmt. 

Bei der Server-Konfigurierung gilt es zunächst, die Standarddienste im 
Netz in ausreichendem Maße bereitzustellen (z.B. Speicherplatz für Ablageeinhei- 
ten) und sie optimal auf entsprechende Rechner zu verteilen. Zusätzlich müssen die 
Anforderungen einzelner Arbeitsplätze berücksichtigt werden (Blackboard). Eine 
besondere Problematik stellt die Optimierung der zentralen Dienste unter 
Performance- bzw. Sicherheitsgesichtspunkten dar. In diesem Zusammenhang gibt 
es nur wenige eindeutige Regeln, dafür umso mehr Daumenregeln: "man sollte 
möglichst nicht ...", "es ist ratsam, ..." etc. Durch Erfahrungen aus der Praxis wächst 
dieses Wissen ständig an. 

Die Ausfallsicherheit eines Netzes spielt bei der Bestimmung der Netzto- 
pologie sowie bei der Verteilung der einzelnen Server auf die Netzsegmente eine 
zentrale Rolle. Werden z.B. alle Server an ein Segment angehängt, wird beim Aus- 
fall dieses Segments das gesamte Netz lahmgelegt. Gerade solche Problemstellung- 
en werden in der Praxis oft nicht ausreichend berücksichtigt. Hier können durch ein 
Expertensystem wesentliche Verbesserungen erreicht werden. 
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Regeleditor 

Um die der Konfigurierung zu Grunde liegende Wissensbasis leicht er- 
weitern zu können, ist in NETCON eine Wissenserwerbskomponente enthalten. Sie 
ist als syntaxgesteuerter Regeleditor realisiert, mit dessen Hilfe die verschiedenen 
Regelmengen in der Wissensbasis komfortabel gepflegt werden können. Der Be- 
nutzer kann neues Wissen hinzufügen und ist dabei unabhängig von der internen 
Repräsentation in der Wissensbasis. Er wird außerdem bei der Erhaltung der Kon- 
sistenz unterstützt, indem die Einhaltung vorgegebener Metaregeln über die 
Struktur und den Inhalt der Wissensbasis vom System automatisch überprüft wer- 
den. 



Erklärungskomponente 

Für die Akzeptanz bei den Endbenutzern ist die Transparenz eines Exper- 
tensystems eine wichtige Voraussetzung. Deshalb ist die Erklärungskomponente in 
NETCON ein fest integrierter Bestandteil. Sie ist in der Lage, dem Benutzer die 
einzelnen Schritte des Problemlösungsprozesses in einer verständlichen Form dar- 
zulegen. Der Benutzer kann den Schlußfolgerungen des Expertensystem folgen 
und somit den Weg, wie eine Lösung zustande kam, überprüfen. 



4 Benutzerschnittstelle 

Da die zukünftigen Benutzer von NETCON mit der Arbeitsweise des 
Bürosystems 5800 vertraut sind, ist die Benutzeroberfläche der dieses Bürosystems 
nachempfunden: sie ist objektorientiert und macht intensiven Gebrauch von den 
zur Verfügung stehenden Window- und Grafikfähigkeiten dieses Systems. 

Für den Benutzer wird zwischen vier verschiedenen Ein- bzw. Ausgabear- 
ten am Bildschirm unterschieden: 

- Icons dienen der graphischen Repräsentation von Objekten (durch sie 

können Objekte ausgewählt werden) 

- Menüs dienen der Auswahl bei Alternativen (z.B. Funktion eines Objektes 

auswählen, Ausprägung eines Arbeitsplatzes festlegen) 

- Textfelder dienen der Ein- bzw. Ausgabe von Text (z.B. Namen erfragen) 

- Gauges dienen der graphischen Visualisierung einzelner Werte (Displays). 

Immer wenn sich ein entsprechender Zahlenwert ändert, wird dies 
automatisch auch visuell dargestellt. Dies eignet sich vor allem für 
Parameter wie Preis, Auslastung der Speicherkapazität, etc. 
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Bild 5: Benutzerschnittstelle mit Arbeitsblatt 



Um sich unterschiedlichen Benutzergruppen anzupassen, gibt es in 
NETCON zwei verschiedene Abstraktionsebenen, auf denen der Benutzer mit dem 
System kommunizieren kann: "funktionale Sicht" und "technische Detailsicht". Bei 
der funktionalen Sicht werden vom Benutzer weniger Systemkenntnisse erwartet. 
Dafür verhält sich NETCON auf dieser Ebene starrer, die Auswahlmöglichkeiten sind 
nicht so flexibel wie auf der Ebene der technischen Detailsicht. Durch die funk- 
tionale Sicht werden auch technische Laien in die Lage versetzt, standardmäßige 
Lösungsvorschläge für ihre Problemstellungen zu erarbeiten. Dagegen werden 
vom Benutzer beim Konfigurieren in der technischen Detailsicht mehr Kenntnisse 
über die Komponenten und ihre Funktionalität gefordert. 
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5 Aufbau der Wissensbasis 



Auf Grund der hohen Anforderungen bzgl. der Flexibilität des Systems 
wurde besonders der Aspekt einer modular aufgebauten und wohlstrukturierten 
Wissensbasis mit komfortablen Modifikationsmöglichkeiten berücksichtigt (Regel- 
editor). Die Zerlegung in verschiedene Regelmengen erfolgt dabei analog zur Auf- 
teilung der Konfigurierer in logisch zusammengehörende Einheiten : 

- Software für APS 

- Hardware fürAPS 

- Software für Server 

- Hardware für Server 

- Netzbausteine (Kabelsegmente, Anschlüsse, etc.) 

Alle Bestandteile des Bürosystems 5800 werden als Fakten zusammen mit 
den dazugehörenden Regeln in einer dieser Regelmengen definiert. Die eigent- 
lichen Regeln werden dabei als Relationen auf bzw. zwischen den verschiedenen 
Bestandteilen realisiert. Sie beschreiben Abhängigkeiten von Software-Paketen 
bzw. Hardwarekomponenten untereinander (Relationen "requires", "HWrequires" 
,...) oder stellen Richtlinien für eine "optimale" Konfigurierung dar (Relationen 
"1 ikes-to-have",.,.). Als interne Repräsentation solcher Regelmengen werden 
Assoziationslisten in LISP eingesetzt: 
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Alle diese zwingenden Zusammenhänge der verschiedenen Systembe- 
standteile stellen kein Expertenwissen im engeren Sinne dar; sie liegen in einem 
technischen Konfigurierungs-Handbuch [3] schriftlich vor. Zur Konfigurierung der 
zentralen Dienste und ihrer Aufteilung auf Server-Hardware ist aber außer diesen 
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festgelegten Regeln auch vages, heuristisches Wissen notwendig, das nur in Form 
persönlicher Erfahrungen der einzelnen Experten vorliegt: 

- Es sind Erfahrungswerte über die optimale Aufteilung von Diensten auf Server- 
HW vorhanden. Hierbei sind in der Praxis vor allem Randbedingungen, wie Per- 
formance und Speicherkapazitäten zu beachten, die in keiner technischen Be- 
schreibung ausreichend berücksichtigt sind. 

- Es existieren Daumenregeln zur Abschätzung von Mengen, z.B. wieviel zentraler 
Speicherplatz bei wievielen Benutzern sinnvoll bzw. minimal erforderlich ist. 

- Anwendungsbeschränkungen, die im laufenden Betrieb eines Netzes festgestellt 
wurden, führen zu "Constraints", die nicht verletzt werden dürfen. Darunter 
fallen alle Aussagen der Art "Vermeide ...". Diese Constraints können nicht kon- 
struktiv zur Projektierung eines Netzes verwendet werden, sondern nur ab- 
schließend auf ihre Einhaltung überprüft werden. 

Beim letzten Beispiel wurde deutlich, daß außer dem Wissen der Konfi- 
gurierungs-Experten auch Erfahrungen aus dem Feld eine wichtige Rolle spielen, 
die von Wartungs- und Bedienpersonal gewonnen werden; es kann ein rückkop- 
pelnder Know-How-Transfer vom laufenden Betrieb zurück zur Planung eines 
Netzes erreicht werden. 

Zusätzlich zum eigentlichen Konfigurierungswissen wird die Darstellung 
der einzelnen Komponenten eines Netzes innerhalb von NETCON als Layoutinfor- 
mation in speziellen Regelmengen hinterlegt. Dadurch kann auch die Benutzer- 
oberfläche des Systems sehr schnell an neue Anforderungen angepaßt werden. 

Um Konsistenzprüfungen durch den Regeleditor zu ermöglichen, wer- 
den Struktur- und Semantik-Informationen der einzelnen Regelmengen als Meta- 
wissen ebenfalls in der Wissensbasis festgeschrieben. Dieses Metawissen umfaßt 
pro Regelmenge Informationen über: 

- obligate Relationen, 

- optionale Relationen sowie 

- Definitions und Wertebereiche der Relationen. 



6 Erfahrungen bei der Projektdurchführung 

Da sich Expertensysteme in ihrer Struktur und Konzeption in beträchtli- 
cher Weise von herkömmlichen Software-Systemen unterscheiden, ergeben sich 
neue Problemkreise, die bei der konventionellen Software-Entwicklung unbekannt 
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waren. Wir haben überden Zeitraum eines Jahres hinweg unsere Probleme und Er- 
fahrungen damit in einem Projektlogbuch gesammelt. Sie lassen sich in zwei Kate- 
gorien einteilen: organisatorische und technische Problemkreise. 

Bei den organisatorischen Problemkreisen lassen sich folgende Schwer- 
punkte feststellen: 

- Durch den Einsatz von Rapid-Prototyping ist ein Phasenplan, wie er bei konven- 
tioneller SW-Erstellung angewandt wird nicht ausreichend. Eine "Misch "-Strate- 
gie, die beiden Aspekten gerecht wird, ist notwendig. 

- Phasenorientiertes Vorgehen beruht unter anderem auf der Abschätzung von 
Aufwänden. Vor allem die Wissenserfassung ist sehr schwierig zu planen, da über 
das zu erfassende Wissen sehr wenig bekannt ist. 

- Durch Einsatz der Programmiersprache LISP und Rapid-Prototyping ist eine 
adäquate Inline-Dokumentation nur sehr schwer möglich; außerdem geht die 
Entwicklung eines Prototypen meist schneller voran, als entsprechende Doku- 
mentationen nachgezogen werden können. Deshalb sind Spezifikationen selten 
auf dem aktuellen Stand. 

- Die Entwicklung konventioneller SW-Systeme bedeutet lediglich den Kontakt 
zum Auftraggeber oder Kunden. Bei Expertensystemen kommt eine neue Kon- 
taktperson hinzu : der Experte, dessen Wissen in das System einfließen soll. 

- Die Experten müssen in ausreichendem Umfang zur Verfügung stehen. Da es im 
allgemeinen zuwenige Experten gibt, ist deren Zeit aufgrund ihrer Tätigkeit so- 
wieso sehr knapp bemessen. 

Als technische Problemkreise wurden vor allem folgende erkannt: 

- Die Expertise liegt bei Fremdpersonen. Das Wissen ist meist tiefgehendes Spezial- 
wissen, nicht oberflächlich und breit gestreut. Es ist deshalb schwierig zu fassen. 

- Expertise muß vorhanden sein. Teilgebiete eines Aufgabenkomplexes, für die 
keine Erfahrungen vorliegen, können auch mit einem Expertensystem nicht ge- 
löstwerden. 

- Das Expertenwissen ist oft "compiliert" in den Experten gespeichert, gewisse Tat- 
sachen sind für sie selbstverständlich und werden nicht mitgeteilt. Die Experten 
erklären oft Fakten und Zusammenhänge, ohne ihre eigene Vorgehensweise bei 
der Bearbeitung eines Falles zu beschreiben. Gerade dieses Problemlösungsver- 
halten ist aber für den Bau eines Expertensystems eine unerläßliche Basis. Fallbei- 
spiele, die gemeinsam mit den Betroffenen durchgespielt werden, sind eine gute 
Möglichkeit zur Reduzierung dieses Problems. 

- Die Konsistenz der Wissensbasis ist nur sehr schwer sicherzustellen. Dies wird 
durch nicht eindeutige und teilweise divergente Expertenmeinungen noch ver- 
schärft. Deshalb sollte man nie zu viele unterschiedliche Experten einbeziehen. 




- Für den Bau eines Expertensystems sind meist mehrere Wissensrepräsentations- 
formen notwendig, um das Wissen in seiner jeweils natürlichsten Form formulie- 
ren zu können. Die Beschränkung auf eine Darstellungsmöglichkeit allein würde 
eine Einschränkung für die Flexibilität und Verständlichkeit bedeuten. Für den 
Programmierer bedeutet dies, eine Mischung der verschiedenen Repräsenta- 
tionsformen und der damit verbundenen Stile beherrschen zu müssen. 

- Es fehlt an Erfahrungen, wie die Schnittstellen zwischen den unterschiedlichen 
Wissensrepräsentationsformen und Inferenzmechanismen zu wählen sind. 
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SUPPORTING KNOWLEDGE REPRESENTATION BY CHECKING CONSISTENCY 

Werner Mel 11s, Paderborn 

Summary: In [1] a simple consistency condition for rule-based expert 
systems Is proved. This paper discusses Its use for a computational tool to 
support declarative representation of knowledge In such expert systems. 

1 The Relevance of Consistency for Expert Systems 

The following Is general In parts, but as a whole deals only with rule 
based expert systems, as rules are the most widely used formalism as know- 
ledge representation in expert systems. 

The reason for the relevance of consistency for predicate logic theo- 
ries is simply, that any formula can be derived from any inconsistent theory. 
Therefore inconsistent theories do not say anything about any world. 

For the usual rule interpreter this is not the case. It is designed to 
allow user answers and to draw conclusions both in a way that keeps the dyna- 
mic knowledge base (the set of user answers and conclusions) consistent. Such 
a dynamic consistency regime is in most cases easy to realize and has a two- 
fold advantage. The first is, that an expert system giving contradictory 
advice would not look very smart. The second advantage is efficiency. When 
one of several mutually exclusive solutions is found, the system could as 
well investigate the other solutions. But since the system knows about their 
exclusiveness, further effort must anyway be in vain. Efficiency can be 
further improved, if the knowledge about exclusiveness 



This work has been partly supported by the German Bundesminister fuer For- 
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of solutions is not expressed in the rule language, but is implicit in the 
interpreter's strategy. 

Using such a dynamic consistency regime, the set of conclusions and 
user answers is kept consistent. Therefore unlike the case of predicate cal- 
culus, there is no set of rules for which the interpreter derives any arbi- 
trary formula. Therefore, the consistency of the static knowledge base is not 
an issue. 

However, when the consequences of the dynamic consistency regime are 
carefully analyzed , another problem appears. The rule interpreter interprets 
any set of rules in a way, that says something interesting about some world. 
The problem is, that the rule set alone does not tell about which. 

To find out which world the interpreter refers to one has to inspect 
the rule interpreter to understand its use of the rules. But this of course 
is just what should have been prevented by the knowledge representation tech- 
nology. 



The point is, that the knowledge engineer should deal with knowledge 
not with its use. That means he should interpret the knowledge he codes just 
as statements about a domain of discourse, i.e. declaratively. He should not 
need to reason about, when it is used, in which sequence etc. He should be 
able to rely on the system's ability to apply the knowledge, when and where 
it is needed. 

The reason, that the rule interpreter does not interpret the rules 
purely declarative is, that the interpreter's provability relation |-'- is 
different from |— the provability relation of predicate logic. A typical 
deviation is, that the rules' interpretation depends on their enumeration in 
the knowledge base. 
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In the most simple case and |— deviate only for Inconsistent 
(with respect to |~) sets of axioms, l.e. for every sentence s: Ax s 
Iff Ax I— s. If Ax Is consistent (with respect to |— ). 

In this case, consistency of the static knowledge base and the user 
answers means, that the conclusions of the inference mechanism are exactly 
those, which are logical consequences of the static knowledge base and the 
user answers. 

Assuming, that the expert formalized his knowledge correctly and that 
he himself used his knowledge correctly and completely, consistency of the 
static knowledge base guarantees that the inference mechanism draws the same 
conclusions the expert draws. 

2 Application: 

Supporting Knowledge Representation by Checking Consistency 

As has been pointed out, static consistency (i.e. consistency of the 
static knowledge base and the user answers) is not an issue per se. The 
issue is to demonstrate, that (for every admissible set of user answers) the 
knowledge base posseses a uniquely determined declarativ interpretation, the 
one the expert had in mind. This is where a checking tool comes in, which we 
call a consistency checker. It is used to help the expert to spell out a 
declarative interpretation of his knowledge base. 

One may wonder whether this is necessary at all, as the expert codes 
the knowledge he applies routinely. But this is not exactly the case. The 
problem is, that he codes the knowledge which he believes, that he uses, not 
the knowledge he actually uses. He may believe that he knows: 

A(x)=w — > B(x)=v and B(x)=v — > C(x)=u 
and later on is convinced that 
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A(x)=w — > C(x)=u' for some u different from u'. 

In fact, he applies two different rules 

A(x)=w — > B(x)=v only in context D and 
A(x)=w — > C(x)=u' only in context non D. 

The knowledge he applies is 
A(x)=w & D — > B(x)=v, 

A(x)=w & non D --> C(x)=u' and 
B(x)=v — > C(x)=u 

and this is consistent, even if A(x)=w holds, but he believes to know more 
general rules. 

This is a typical example of how an expert's tendency to overgenera- 
lize leads to inconsistencies. There are different ways to solve this pro- 
blem. One way is deviating from the provability concept of first order predi- 
cate logic. This is what the dynamic consistency regime of the rule inter- 

preter does to prevent proving inconsistencies from consistent sets of axi- 
oms. One can deal with this by learning how the interpreter works, but that 
means leaving the idea of knowledge representation. Provocatively, this has 
been called programming in rules instead of representing knowledge. 

To support representation of knowledge one should not deviate from the 
provability concept of predicate logic, but should instead rewrite the axiom 
set. On the other hand programming in rules, when properly done has its own 
virtue in terms of efficiency. Therefore a dynamic consistency regime should 
be employed and in addition rewriting the axiom set should be accomplished in 
a way which conforms to the rule interpreter's deviation from the provability 
concept. This can be reached by making the axioms' use explicit, i.e. by 
rewriting the axioms, so that they express the conditions under which the 
consistency preserving interpreter will use them. 
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Formally this means, there Is a provability concept different 

from provability in first order predicate logic I—, such that 
for every set Ax of axioms Th Ax * := {scS| Ax|-*- s} 
is consistent (with respect to |— ) 
and if Ax Is consistent (with respect to |— ), then Th Ax * =Th Ax . 

Our approach to support knowledge representation in rules means defi- 
nition of a mapping c: |P(S) — > |P(S), such that 

for every set Ax of axioms, Th Ax * =Th c (Ax) 
and therefore also 

( + ) Th Ax = Th c(Ax) » if Ax is consistent (with respect to |— ). 

While the replacement of |— by |-*- is a step towards procedural programm- 
ing, i.e. one has to learn, how the interpreter uses the rules, replacement 
of Ax by c(Ax) is a step toward explication of one's knowledge. 

For (+) one could simply define c(Ax) = Ax for every consistent set 
Ax. But we prefer to replace every set Ax of axioms by a set c(Ax) satisfy- 
ing the disjointness condition defined below. The advantage is twofold. Dis- 
jointness is much easier to check than consistency and spells out hidden rea- 
sons for consistency, thus making the knowledge more transparent. Further 
disjointness guarantees consistency of the knowledge base for every admissi- 
ble set of user answers. But it is not a necessary condition. There are 
knowledge bases which are not disjoint but nevertheless consistent (for every 
set of admissible user answers). For example 
A(x)=w — > C(x)=u, 

B(x)=w — > C(x)=u 1 (u=/=u 1 ) , 

D(x)=v — > A(x)=w and 
D(x)=v' — > B(x)=w, 

when v and v' are the only admissible values for D. 

This knowledge base is consistent, because A(x)=w and B(x)=w are not 
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deducible simultaneously. However, the consistency checker in its simplest 
form identifies this as a problem and proposes to substitute the second 
clause 

B(x)=w — > C(x)=u 1 by B(x)=w & A(x)=/=w — > C(x)=u 1 
or some alternative. This substitution makes the meaning of the clause in the 
knowledge base explicit. One may note that this does not mean to make the 
clause in some respect context dependent. Firstly it expl i cates the "context 
dependency" and secondly the substitution which it leads to yields an opera- 
tionally equivalent knowledge base. 

Thus the expert can write down his associations as overgeneralized as 
they occur to him, and then can rely on the consistency checker to find out 
whether they have to be further constrained. If so, the consistency checker 
replaces them by a consistent set of axioms, which is operationally equiva- 
lent to the original, thus spelling out how the dynamic consistency regime 
would interpret it. The expert can easily check the proposal, as he just has 
to check whether the new axioms hold. 

One might provide the expert with explanations about the inconsisten- 
cies. When for example the expert thinks, that some proposal of the system is 
a too narrowly restricted rule, he might want to ask for the rational of this 
proposal. It might be helpful for him to know which rules conflict, in order 
to decide whether there are alternatives to the system’s proposal. 

3 The Interpretation of Associative Triples in Predicate Logic 

Many expert systems use the language of associative triples, i.e. 
atomic formulae are (obj,attr,val)-triples. In the predicate logic version, 
the universe usually consists of two sorts of elements, called object- 
instances and values. In an associative triple (obj,attr,val) "obj" is an 
object variable varying over the set of object- instances or a constant 
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denoting an object-instance, "attr" Is an attribute Interpreted to be a map- 
ping from object-instances to values and "val" denotes a value of the uni- 
verse. An associative triple (obj, attr, val) is Interpreted to mean that 
"val" Is the value of the object- Instance denoted by "obj" under the mapping 
denoted by "attr". 

Example 

for every organism: 

if (organism, gram, gramneg) and (organism, morph, rod) 
then (organism,identity,bacteroides) 

In its contents this rule is similar to a rule in MYCIN'S knowledge 
base. From a biological point of view it is not valid. But this is 
irrelevant here. It means that the identity of organisms is bacteroi- 
des, if their gramstain is negativ and their morphology is rod. 

For obvious reasons, it is very popular to restrict axiom sets to con- 
sist of Horn-clauses. If attributes are interpreted as relations, sets of 
Horn-clauses are consistent. This is not the case if they are interpreted as 
above, (i.e. as mappings). In this case (obj, attr, vail) and (obj, attr, val2) 
are contradictory, if vail and val2 refer to different values. 

To prevent investigation of the semantics of associative triples, an 
interpretation of the language of associative triples in sorted first order 
predicate logic is used. According to the above discussion, associative tri- 
ples (object, attribute, value) are mapped onto sorted first order atomic for- 
mulae R(x, value). This means, that for a given language of associative tri- 
ples, the associated first order language contains for every attribute a 
binary relational symbol, whose first argument is restricted to the sort of 
object instances and whose second argument is restricted to the sort of 
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values. To express the interpretation of attributes as mappings, additional 
axioms, which are called constraints, have to be introduced. Let valuel and 
value2 be two admissible values for the attribute, then a constraint 
non R(x, valuel) v non R(x,value2) has to be added to the associated axiom 
system in predicate logic in order to ensure its equivalence to the initial 
axiom system in the language of associative triples. 

In the following only countable (possibly infinite) universes are con- 
sidered, which is not a very severe restriction for computational purposes. 

4 The Disjointness Condition 

In this section we shall give a sufficient criterion for consistency 
of certain classes of axioms. The reader interested in full details should 
see [1]. Here we shall restrict ourselves to introduction of the main con- 
cepts and to formulation of the theorem. 

We assume L to be a first order language without identity, with coun- 
tably many non-logical symbols. 

The following two definitions characterize the classes of axioms we 
are dealing with. 

Definition: 

A constraint is a finite disjunction of negated, atomic formulae. 

Definition: 

A simple axiom system is a set of constraints and Horn-clauses. 

For the formulation of the consistency condition we need the following 



technical terms. 
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Definition; 

The conclusion of a Horn-clause A is A, if A is atomic. If A = 
(B— >C), then the conclusion is C. 

Definition: 

Let A be a simple axiom system and C a constraint. 

The complete Horn-clause-set for C in A is the set of every Horn- 
clause in A, whose conclusion contains a relation symbol R occuring in 

C. 

Now it is possible to define the consistency condition. 

Definition: 

Let M be a set of Horn-clauses with H j = A j --> B j . 

M is called disjoint for a set N of constraints, iff for every C c N 
with C = non C i v ... v non C and for every substitutions s, s \ , 
... , s m ,if (after renumbering of M) C i (s) = B i (s \ ) for i = 1 
, ... , m , then the set { A \ (s \ ), ... , A m (s m ) } is not 
satisfiable in a common model. 

A simple axiom system A is disjoint iff for every constraint C in A 
the complete Horn-clause-set for C in A is disjoint. 



Theorem: 

Every simple, disjoint set of axioms is consistent. 

The idea of the proof basically consists in incrementally constructing 
an Her brand-model of the axiom set. A formal proof is given in [1]. Here the 
emphasis is on the theorem's significance. 
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5 Discussion 

5.1 The condition of the theorem is not necessary. 

There are axiom systems which are consistent, but do not satisfy the 
disjointness condition. For example the axiom system: 

R i (a) 

R i (b) — > R 2 (a) 

R i (b) -> R 2 (b) 
non R 2 (a) v non R 2 (b) 

is consistent, iff a and b are different terms. But the axioms are not 
disjoint. The reason is: R \ (b) is not provable, i.e. there are 

models, in which R \ (b) is false. For example: 

U = {a,b}, I (R 1 )={a}, I(R 2 H }. 

5.2 Disjointness is not restrictive. 

For every simple, consistent axiom system, there is an equiva- 
lent, simple, disjoint axiom system. 

Let A be a simple, consistent axiom system and let C = non C i v...v 
non C k be a constraint in A. If A is not disjoint, there are Horn- 
clauses H i = A f — > B j for i=l,...,k and substitutions s, s \ , ... 
, s k , such that C i (s) = B j (s j ). Let s, s \ , ... , s k be the 
most general such substitutions for H -j and C. Let {v i ,...,v j } be 

the set of all variables free in H \ (s i ), ... , H k (s r ) which 

are not free in C(s). Let r be the substitution of { v j ,...,v j } by 
some constant a. Let N -j be A i (s i ) & ... & A i_i & A j+i (s i+i ) 

& ... & A k (s k ) and H' -j = A -j & non N ] (r) — > B j . 
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It is easy to prove that H *j and H* ^ are equivalent, if A is 
consistent. Therefore, the replacement of H -j by H' i for i=l,...,k in 
the axiom set A yields an equivalent set of axioms A'. Iteration of 
the transition from A to A* and reformulation of H 1 -j using De 
Morgan's rules, yields a simple, disjoint set of axiom A" equivalent 
to A. This procedure Is the basis for a consistency checker which we 
have implemented. 

5.3 The use of disjointness 

If a simple axiom system A is consistent, but not disjoint, 
then the reason for consistency is, that there is a constraint C = non 
C i v...v non C ^ in A, that there are Horn-clauses H -j = A — > B ^ 
for 1=1,..., k in A and that there are substitutions s, s \ , ..., s k 
such that C j (s) = B ] (s j ), but that the conjunction A \ (s \ ) & 
... & A k (s k ) is not provable from the axioms. 

As can be seen from the above argument, replacing the consi- 
stent, simple axiom system by an equivalent, disjoint, simple axiom 
system, only spells out in detail the reason for consistency. 

It has been pointed out that static consistency is not an issue per 
se. It is used to demonstrate that the knowledge base possesses a uni- 
quely determined declarative interpretation and that this is the one 
the expert had in mind. 

This can be reached by making explicit the axioms' use, i.e. 
by rewriting the axioms, so that they express under which conditions 
the consistency preserving interpreter will use them. For reasons of 
simplicity we will restrict ourselves to the simplified case, mentio- 
ned above, where the rule interpreter successively tries all rules of 
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some ordered list and stops, as soon as any rule succeeds in proving 
some value for the given object and attribute. 

To make this dynamic consistency regime explicit only requires 
the mapping of the given rules to a disjoint, equivalent version as 
described in section 5.2. The notion of disjointness here proves its 
value: it is easy to check and gives the knowledge engineer exactly 

the information he needs. 

An example: 

Given the ordered list of rules: 

rule 1 : A i — > B(v \ ) 

rule 2 : A 2 — > B(v 2 ) 

rule n : A n — > B(v n ) 

then rule n will be mapped to the rule 

non A i & non A 2 & ••• & non A n _\ & A n — > B(v n ) making it 
disjoint with the others. 
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ABSTRACT 

During these last few years, there has been criticism of the first generation 
Knowledge-Based Systems, though it isn't really possible to specify what are the limitations 
of the performance of such systems: 

- is there a lack of flexibility ? 

- or is that they can't solve particularly difficult problems ? 

However, there is no doubt that Expert Systems such as MYCIN, which rely exclusively 
on a problem solving knowledge, have limited capabilities to explain their reasoning. 

The general system CQFE exploits both a " shallow " knowledge, the problem solving 
expertise, and a Conceptual Model, the description of the objects and concepts which 
organize this expertise. An explanation module uses this " deep " knowledge in order to 
reason about the expert system's reasoning, thus providing the user with more adapted and 
relevant explanations. 



ZUSAMMENFASSUNG 

Seit einigen Jahren werden die Systeme mit Wissensbasen kritisiert, die zur ersten 
Generation gehören, ohne daß es möglich ist, die Grenzen der Leistung solcher Systeme 
wirklich zu kennen: 

- Sind diese Systeme nicht genug flexibel ? 

- Können sie keine besonders schwierigen Probleme lösen ? 

Es besteht jedoch kein Zweifel, daß sie eine Begrenzung haben: Expertensysteme wie 
MYCIN, die, um ein Problem zu lösen, nur ein Wissen besitzen, haben begrenzte 
Fähigkeiten, um ihre Schlußfolgerungen zu erklären. 

Das System CQFE benutzt ein " oberflächliches " Wissen: die fachmännische 
Untersuchung eines Problems, und zugleich ein begriffliches Modell: die Beschreibung der 
Objekte und Begriffe, die dieser Untersuchung als Grundlage dienen. Das Erklärungs- 
system benutzt dieses " tiefe " Wissen, um über die Schlußfolgerungen des Experten- 
systems nachzudenken, damit der Benutzer angebrachtere und besser verarbeitete 
Erklärungen bekommt. 



Schlüsselwörter: Erklärungssysteme, Wissensrepräsentation 
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1 Introduction 

It seems important to us that, like a human expert, an Expert System (ES) should keep a 
certain distance towards its reasoning to explain it. But the fact that the expertise relies in 
most cases only on a shallow knowledge [8], represented by rules, doesn't provide it this 
necessary distance. Such a system is unable to: 

- isolate the important steps of its reasoning. 

- emphasize the interesting concepts and give importance to relevant facts. 

- structure its explanation. 

To overcome these defects, we explicitly represent, in what we have called a Conceptual 
Model, the description of the objects and concepts of the domain that organize the problem 
solving expertise. 

This new knowledge provides the ES with a deeper understanding of its reasoning: it 
notes which objects it is reasoning about, what point of view has been chosen about them 
and it can judge the importance of the deduced facts. The system then uses this new 
understanding to summarize its reasoning. 

These ideas have been embodied in the general system CQFE [9] [10] whose architecture 
is organized around the inference engine TANGO [2] [12] and the Oriented-Object language 
MERING [3] [4]. 

An ES in technical diagnosis is presented to illustrate our approach: the application 
concerns the troubleshooting of an industrial device, a travelling crane which lifts up objects. 
The study of this device, the qualitative and quantitative analysis of its reliability, has been 
realized by J.F BARBET and is recorded in [6]. 

The next section presents the knowledge base of CQFE, which contains both the rule 
base and the Conceptual Model. The way the explanation module functions will be discussed 
in section 3. 



2 Knowledge representation in CQFE 



In this section, we take into account that the problem solving expertise has already been 
represented by a set of rules: let us now specify how the Conceptual Model is acquired from 
that knowledge base. 
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2,1 Obietcs and Concepts 

The language used to express the rules associated with the inference engine TANGO is 
the predicate calculus. Thus, this simple rule: 

if (control-light ?x ?y) (state ?y off) 
then (not (supplied-with-current ?x)) 



states that: " if the power-control light of an electrical device is off, then there is no power 
in this device 

The reader can observe that the concepts of " electrical device " and " light " have 
disappeared when we have written the rule and are now implicit: they correspond to the type 
of the variables '?x' and '?y'. 

Once the rule base is constituted, the user can easily put together all the predicates which 
correspond to the same type of objects. 

Thus, for the type " electrical device ", he would get a structure like this: 



/ \ 

electrical-device 

control-light 

power-switch 

supplied-with-current 

connected-to 

\ / 



e.g. a kind of empty frame with slots corresponding to predicates. 

First of all, he can characterize the predicates with knowledge which couldn't be 
represented by rules: 

" an electrical device generally has one power control light which can be in two 
states (on, off); it has just one power switch, but it can be connected to many other 
electrical devices ..." 

This description defines to a certain extent a "typical" electrical device: we give the name 
concept to the entity the user thus obtains. 

Now, let us suppose that a part of the expertise is concerned with the "lifting motor", 
which is a particular motor: the entity "lifting motor" is an object , instance of the type 
"motor" which itself is a specific type of "electrical device". All the entities are thus 
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connected with hierarchic links of the type IS- A. These links correspond to new knowledge 
that the user represents in the Conceptual Model: the example below shows that these 
knowledges may be quite complex. 

We may have effectively many points of view on the same device: for example the 
motor is an electrical device if we take into account electrical failures; but it's also a 
mechanical device if we search for a mechanical failure. It depend^, of course, on the 
problem solving knowledge. 

2.2 The Conceptual Model 

The network of entities we have just defined constitutes the Conceptual Model. We claim 
that these entities (objects and concepts) organize the problem solving expertise of our 
system. 

To represent such knowledge, we use the object oriented language MERINO: 

- the objects and concepts are then represented by two kinds of MERING's units, the 
" instance " and the " type ”, which are respectively defined by the LISP functions " 
defrep " and " defent 

- variables (mode, domain...) characterize the slots and allow the representation of the 
desired knowledge. 

- many points of view can be defined on the same unit. 

We show below the translation of the structures "electrical device" and "lifting motor". 



/ \ 

(defent electrical-device ~ device 
(control-light ~ slot 
(domain = ’light) 

(mode = $uni)) 

(supplied-with-current ~ slot 
(domain = boolean) 

(connected-to ~ slot 

(domain = ’electrical-device)) 

) 

V : ) 
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(defrep lifting-motor ~ motor 
(connected-to = 'battery) 

) 



2.3 The Architecture of COFE 
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FIGURE 1 



It is important to note that the problem solving part is not affected by the new knowledge 
representation: the system's reasoning is conducted by the inference engine TANGO from 
causal production rules. 

The only modification concerns in fact the working memory in which the notion of object 
is introduced. When the facts: 

(supplied-with-current lifting-motor) 

(connected-to lifting-motor battery) 

are deduced, we can say that CQFE is reasoning about the object "lifting-motor". The 
working memory is then made up of these objects of reasoning which are explicitely 
represented. 

The deductive mechanism of properties inheritance is not used at the same time as the 
modus ponens. This conception of deep knowledge particularly differs from that of 
"multi-level systems" such as IDM [5] where the deep knowledge is also a problem solving 
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knowledge. 

In the case of CQFE, rather than defining a reasoning strategy, we shall speak of an 
explanation strategy. As we show in the next part of the article, we conceive the process of 
explanation as a new formulation of the reasoning: during that process the knowledge 
contained in the Conceptual Model is used. 



3 The Expla n ation M odule 



The objective of this module is to explain, as clearly as possible, the whole reasoning 
followed by the ES (note that in such ES as MYCIN, NEOMYCIN [1] [7] or XPLAIN [15], 
the explanation module presents only one step of the reasoning). To reach this objective, the 
explanation module successively 

a) builds a representation of the reasoning based on both the notion of deduction tree 

and that of "object of reasoning" (which we have introduced in section 2.3). 

b) uses the knowledge contained in the Conceptual Model to detect the relevant facts. 

c) ties its explanation to a failure script comprehensible to the user. 

These three points are discussed in the next three sections. 

3.1 Struc t uring t he re asoning 

The first way of representing the reasoning followed by the ES to demonstrate a goal, is 
to build a deduction tree: figure 2 shows such a tree, obtained with our current diagnosis 
application. This simple trace of reasoning is however quite far from any human explanation 
structure. 

On that point, we found that when bringing together all the facts corresponding to the 
same object, we made object blocks appear (see figure 2). We claim that showing evidence 
of these "object blocks", which constitute distinct parts of the deduction tree, provides the ES 
with a better understanding of its reasoning. 

In a first stage, the explanation module structures the reasoning by making these object 
blocks appear. 
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3.2 Simplifying the reasoning 

Now, let's examine another point: all the facts that have been considered by the ES, 
during the problem solving are not necessarily relevant to an explanation. When eliminating 
irrelevant facts, this allows the ES to underline the important steps of the reasoning. 

The relevancy of facts is defined according to the Conceptual Model: the description of 
the objects and concepts of the domain corresponds to a " prototypical " knowledge, which 
does not change from one session to the next; we can thus assume that these descriptions are 
known by the user 

- who is used to manipulating the ES. 

- who already knows about the concepts of the domain and who is more interested in 
the way the system manipulates these concepts, e.g. with the problem solving 
knowledge. 

The facts that are already contained in the Conceptual Model are thus irrelevant facts. The 
explanation module, in a second stage, erases all these irrelevant facts from the structured 
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deduction tree. 



3.3 Tying the explanation to a failure script 

The explanation methods discussed in sections 3.1 and 3.2 are still not complete: the 
explanation module is effectively able to structure and simplify the reasoning but it can't 
make sense out of the links between the object blocks. 

In detailing deduction trees, obtained through our diagnosis application, we discovered 
the following point: 

- a session always consists of first proposing a diagnosis, showing the component 
which is at the origin of the failure, then of confirming this diagnosis, showing how 
the failure explains the situation observed by the user, e.g. detailing the failure script - 

Explicitely presenting the diagnosis and detailing the failure script appears to be a 
convenient explanation: it allows the user to understand the mechanism of the failure. But 
both the general strategy and the functioning conditions of the different components are 
implicit More work needs to be done on the knowledge representation. 

To that effect, the description of the entities of the Conceptual Model has been extended to 
represent the functioning conditions of components: a new variable well-functioning 
describes the conditions of well functioning: 



/ \ 

(defent electrical-device ~ device 
(supplied-with-current ~ slot 
(domain = ’boolean) 
(well-functioning = true)) 
(power-switch-position ~ slot 
(values = ’(ON OFF)) 
(well-functioning = ’ON)) 

... ) 

\ ) 




In a third stage, the explanation module uses this new knowledge to tie the explanation to 
a failure script and to present explicitely the diagnosis. 

From the deduction tree presented in figure 2, CQFE will finally provide the user with 
the explanation text of figure 3: the character reminds the user that he has given the fact. 



faulty components 

1 -> pipe-usual-station 

defective: true 
leaks: true (*) 

2 -> usual-station 

loss-of-pressure: true 

1 caused 2 

Origin of the failure: 1 

Justification of the fact: (stopped handling) 

3 -> usual-brake 

tightened: true 

and 2 caused 3 

Thus, I deduced that: (stopped handling) 



FIGURE 3 



In figure 4, the script is somewhat different: the object has fallen; two faulty components 
are the cause of the failure. 
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faulty components 

1 -> lifting-motor 

defective: true (*) 

2-> sill 

fixed-to-high: true (*) 

3 -> system 

picked-up-speed: true 

4 -> speed-detector 

defective: true 



1 caused 3; 2 caused 4 
Origin of the failure: 1, 2 
Thus, I deduced that: (has-fallen object) 

FIGURE 4 



4 Conclusion 

An ES built according to the framework of CQFE uses both a shallow knowledge, which 
is the problem solving expertise, and a deep knowledge, which is a knowledge base for 
explanation. 

The deep knowledge provides the ES with a better understanding of its reasoning or, to 
put it differently, it allows the ES to keep a certain distance from its reasoning; so the ES is 
able to resume its reasoning. 

This study brings a new light on the simultaneous use of shallow and deep knowledge in 
KBS. 

More over, the explanation module makes use of different kinds of metaknowledges. 
Some are knowledges about the own ES's knowledges: 

" such a fact is important, such an inference is not relevant " 

others are knowledges about the user's knowledges : 

" the user is already aware of the description of i lie concepts of the Conceptual 
Model ” 
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We are convinced that this way of considering explanation as reasoning about reasoning 
is very promising: this study is actually pursued in a new research into the different kinds of 
"metaknowledges for explanation" [11], in order to better understand how the explanation 
module works and to improve its performances. 
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INTERVALS 
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Zusammenfassung: Die bisherigen Wissensrepräsentationsparadigmen und Algorithmen 
für Deduktionen über zeitliche Beziehungen können zwei Gruppen zugeordnet werden ; die 
" zeitachsenorientierten ” Modelle sind transparent und effizient, besitzen aber nur begrenzte 
Ausdruckskraft; bei den ” beziehungsnetz” -orientierten (z.B. die Intervallalgebra von J. Allen) ist die 
Lage umgekehrt. Der hier vorgestellte Ansatz stellt eine Art Syntese beider Gruppen dar. Es umfaßt 
1) eine Wissensrepräsentation mittels ” transitiver Ketten” , die durch die Ausnutzung von formalen 
transitiven Eigenschaften der qualitativen Intervallrelationen (im Gegensatz zu dem 
” Referenzintervallmodell” , welches das domainspezifische Wissen heranzieht), die Effizienz und 
Transparenz der zeitachsenorientierten Ansätze erreicht, ohne auf die Ausdruckskraft des 
Beziehungsnetzmodells zu verzichten, 2) den Algorithmus für den dynamischen Aufbau der 
transitiven Ketten und die Constraint Propagation darin sowie 3) eine nichtmonotone Erweiterung des 
Grundalgorithmus, die die Rücknahme von eingeführten Constraints erlaubt. 



Abstract: The representation paradigms and algorithms developed in the past for making 
inferences about temporal relations can be classified into two groups: the ”time line” models are 
transparent and efficient, but of limited expressive power; in the ” relation network” model (e.g., the 
interval algebra of J. Allen) the situation is the inverse. The paradigm presented here represents a 
kind of synthesis of both approaches. It comprises 1) knowledge representation through ” transitive 
chains” , which retains the efficiency and transparency of the time line approach without sacrificing 
the expressive power of the relation network model, using the formal transitive properties of the 
qualitative time event relations (in contrast to the ” reference interval ” model which implicitly uses 
domain knowledge) , 2) an algorithm for dynamic maintenance of transitive chains and constraint 
propagation within them, and 3) a nonmonotonic extension of the basic algorithm which permits the 
retraction of constraints. 



1 Introduction 

The necessity to enable knowledge to be provided with time references has been widely 
recognized. The domains particularly concerned are planning, qualitative modelling, natural 
language understanding, and database systems. Several theoretical logic systems, extending the 
classical logics through time operators (e.g., [10]) or providing object language statements with 
time references (e.g., [2]), have been proposed. However, the algorithmic realization of such a 
full-scale inference system including time reference facilities represents a formidable problem. 
Alternatively, isolated time reasoning specialists have been developed, which store and retrieve 
the time references, ensuring the consistency by constraint propagation. Such time specialists can 




be then linked into a full-scale temporal inference system. 



From the paradigms investigated in the past, the interval based model according to J. 
Allen [1] is doubtlessly one of the most expressive ones. It is capable of expressing all qualitative 
relations between two relations as well as incomplete information. Shortcomings of this powerful 
representation are its relative computational inefficiency and high storage requirements of its 
relation network. Additionally, the relation network is not transparent: it fails to represent in any way 
the existence of the time flow. 

To be applicable to domains like planning and qualitative modelling, the time reasoning 
assumptions have to be retractable, i.e., some kind of nonmonotonicity must be introduced. This 
represents a nontrivial problem. 

In this paper, a representation and a constraint propagation algorithm are presented 
that improve substantially the efficiency and transparency of Allen's basic model, without loss of its 
expressive power, using formal properties (transitivity) of certain elementary time event relations. 
Further, management of dependencies has been implemented, which enables the retraction of 
constraints and other TMS operations. 

In Section 2 an algorithm is presented, which tackles successfully the problem of 
efficient representation. 

A straightforward nonmonotonic extension of the algorithm is given in Section 3. 

An assessment of the computational effectiveness gain is sketched in Section 4. 

2 Transitive chain approach 

2.1 Preliminary observations 

Among the present time reasoning paradigms, two classes can be recognized: 1) those 
using some kind of quantitative or qualitative time line (e.g., the data lines and the before/after 
chains of [9]) and 2) those using a network of pairwise relations (interval algebra of Allen [1]). 
The former class is relatively computationally inexpensive and transparent (the whole set of events 
is easy to represent in an "overall view”), while its expressive power is limited. The latter class is 
the reverse. 

Obviously, there is a strong motivation for a synthesis of the time line and the relation 
network approaches (for more details on representational aspects of the synthesis, see [8]). 

The representation and algorithm proposed in this paper are based on the following 
observation. The human reasoning about time events makes use of certain transitivity properties. 
E.g., given the relations "having breakfast" before "driving to the office”, "driving to the office” 
before "driving home", and "driving home” before "having dinner”, "having breakfast” before 
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" having dinner” can be inferred without considering an explicit relation between "having breakfast” 
and "having dinner”. Other intuitively transitive relations are starts before, finishes before, and 
contains. It is certainly conceivable to represent relations between time events in this 
"nonredundant” way, omitting the explicit connections between those events, whose relations can 
be derived from the transitive properties of other explicitly considered connections. 

To represent this mental model, let us introduce the concept of transitive chain. It is a 
directed graph, whose nodes are the individual events, and whose edges are the explicit relations 
between them. Under certain conditions, the relation between two not explicitly connected events 
can be inferred from the fact that there is a path through the graph between these two events. The 
relations which cannot be inferred from the transitive chain have to be considered explicitly (see 
Fig. 1). 




«■hh transitive chain 

■ explicit connections 

Fig. 1 A transitive chain. 

2.2 Requirements on transitive chains 

There are some requirements for the transitive chains to be a suitable representation for 
inference systems : 

Requirement 1 : No information should be lost in comparison with the basic model. 
(E.g., in the "reference interval” model [1], some inferences can be prevented by an 
inappropriate reference interval structure.) 

Requirement 2 : A relation represented only indirectly by a path in a transitive chain 
should be deducible from the mere existence of the path (without necessity of multiple 
computationally expensive transitivity table accesses along the path, see [1]). 

Requirement 3 : The transitive chains should contain complete information about the 
relations involved, i.e., information which cannot be further constrained. In other words, if two 
events are ordered by the transitive chain, it should be deducible from this fact that there is a 
unique elementary relation (without further alternatives) between the two events. Otherwise (in the 
case of several alternative admissible relations) , this constraint could possibly be in future further 
constrained. Since this additional constraint would not be deducible from the chain, a 
reestablishment of an explicit relation would become necessary for the additional constraint not to 
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be lost. 



Requirement 4 : The constraint propagation algorithm should use only explicit 
connections, making no request for relations which have to be inferred from the transitivity chain 
(to prevent frequent computationally expensive path searches) . 

2.3 Formal properties of transitive chains 
First, let us introduce some denotations: 

- The function symbol trans(ij) denotes an entry in the transitivity table, i.e., the 
constraint imposed on the relation between events A and C (or, in other words, the set 
of possible relations between A and C) if the relation between A and B is constrained to / 
and the relation between B and C is constrained to /. (For the transitivity table concept, 
see [1].) 

- The function transitions(l,J) corresponds to Allen's constraint$(l,J): it is the union of all 
trans(ij) such that iGl and jGJ- 

- R(i,j) denotes the relation between the intervals / and /. 

- S denotes the set of all elementary relations. 

- SScS is the characteristic set of a transitive chain; for any two directly connected 
chain members / and / must be R(i,j)c:SS. 

Let us now specify three formal properties which can be useful for defining transitivity 
within the set S of some exclusive elementary time event relations. 

Definition 1 : A chain is uniform, if for all ijGSS : trans(ij) = f(SS), f(SS)dSS. 

The relation between any two (not directly connected) members of a uniform chain is 
uniformly SS. A uniform chain meets implicitly Requirements 1 and 2 : no information along a chain 
path is lost, the relation between any pair of not directly connected events is completely 
determined. However, a further constraining of this relation is possible unless the chain is 
unambiguous. 

Definition 2 : A chain is unambiguous, if for all ijGSS: trans(ij) = {ffSSJ}, ffSSJeSS. 

The relation between any two members of an unambiguous chain is unambiguous. 
There are no alternative relations, the relation cannot be further constrained. An unambiguous 
chain obviously meets Requirement 3. 

Definition 3 : A chain is monotonous (in relation to unchained nodes), if for all 
S1,S2czSS and all RdS : 

transitions (S 1 , transitions (S2,R)) dtransitions ( transitions (SI, S2) , R) and 
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transitions (transitions (R,S1), S2) dtransitions ( R, transitions (SI , S2)) , 

In other words, the direct constraint via two chained relations is always less constraining 
than the successive constraint propagation via them. An unambiguous and monotonous chain 
meets Requirement 4 (Fig. 2) : in a constraint "triangle” (i,j,k), whose connection (i,j) is 
substituted by a chain path (the connections (j,k) and (i,k) being explicit) the constraint 
transitions(R(k,i) ,R(i,j)) via the nonexplicit connection (ij) is never sharply stronger than the 
constraint transitions(R(k,iO),R(iO,j)) via the explicit connection (iOj), where iO is the neighbour 
node to j on the path between / and /. The connection (k,iO) is explicit except it is a chained 
connection (making the connection (k,j) redundant, because of unambiguousness of the chain). 




Fig. 2 Monotonicity. 

Note 1 : The property names used above are in no way related to similarly denoted 
mathematical properties. 

Considering the special case of 13 basic interval relations, the following subsets (and 
their inverses) are uniform, unambiguous and monotonous: {<,m} (before/after ordering), {d> 
(sharp containment) , (s) (containment of intervals with common beginnings) , {f} (containment of 
intervals with common ends) and, of course, {=> (equality). 

Note 2 : All algorithms in this paper have been applied to this set of 13 interval relations, 
considering a single transitive chain {<,m}, which seems to be the one of the greatest importance 
for our intended applications (the containment chains being typically not very long). However, 
several chains can be considered simultaneously, e.g., {<,m} and {d}. Of course, an alternative 
relation set (e.g., a time point relation set, see [11]) can be implemented, too. 

2.4 The algorithm 

The algorithm for adding a constraint consists of two steps: 

Step 1 : Constraint propagation as in Allen’s basic algorithm is performed. A relation 
which has been constrained to become a member of a transitive chain is put into the ’’chaining 
queue”. ( CR is the characteristic set of the chain.) 

Step 2 : For each relation (ij) in the chaining queue, two sets are defined: the set SB of 
all nodes which are before the inserted pair, and the set SA of all nodes which are after the inserted 
pair. All ’’cross connections” (i.e., explicit connections between / and members of SA, between 
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members of SB and /, and between members of SB and members of SA) are deleted. 

Algorithm 1 : 

modify _re!(i, l, NewRel) 
update pel (i ,j ,NewRel) ; 

process pueue ( constraint , constraint _ propagation ) ; 
process pueue ( chaining , chaining propagation) 

with 

update pel (rl ,r2, NewRel) 

H+-NewRel; 

If H-R(r1,r2) then add_to_queue ( constraint, rl ,r2) ; 

If HczCR & not R(r1,r2)dCR then add Jo pueue ( chaining ,r1 t r2) ; 
R(r1,r2)4-H; 

constraint propagation (i ,j) 

For each k such that triangle(i,j,k) do 

begin 

update _rel(k,j, transitions (R(k,i), R(i,j) )); 
update_rel(i,k,transltlons ( R ( i,j ) ,R(j,k) ) ) ; 

end 

chaining propagation (i,J) 

For each k such that before(k,i) 

For each / such that before(j,i) 

For each k,l such that before(k,i) & before(j,l) 



Auxiliary functions are defined as follows: 

- The function transitions (R1 ,R2) corresponds to Allen’s constraints(R1 ,R2) , as stated 
before. 

- The Boolean function triangle (i,j,k) returns true, if all three time event pairs ( i,j),(j,k ), 
and (k,i) are explicitly connected. 

- The Boolean function before(ij) returns true, if there is a path through the transitive 
chain from the node / to the node /. 

- The function process _queue (queue Jd , queue proc) calls for each item (i,j) in the queue 
queue Jd the procedure queue proc(i,j). 

- The function delete ponnection (i J) deletes the explicit connection between the intervals 
/ and /. 

- The functionality of addjopueue is obvious. 

Note 3 : The incompleteness of Allen’s constraint propagation algorithm, as stated in 
[11], has been neglected. However, any other (complete) constraint propagation algorithm may 
be substituted for the Allen’s, having no influence on the transitive chain maintenance. 



do deleteponnection(kj) ; 
do delete ponnection ( i } l) ; 
do delete ponnection ( k,l) ; 
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Example 1 : Let us have 4 intervals A,B,C,D with initial external constraints A — [<,m] 
— > B, C — [<] — > D and A — [<,o,s] — > C. Fig. 3a shows the relation network after the 
completed constraint propagation. Imposing a further constraint, B — [<,m] — > C, the constraint 
propagation takes place, resulting in potential chain edges A — [<] — > C, B — [<] — > D, and A 
— [<] — > D (Fig. 3b). (B,C), (A,C) and (B,D) are put into the chaining queue. Processing (B.C), 
the set of all elements before B on the chain - {A} - and the set of all elements after C - {D} - are 
determined and all superfluous connections, i.e., (A,C), (B,D) and (A,D), are deleted. 
(Processing the rest of the chaining queue may now be dropped since all connections in it happen 
to have been deleted in the first step.) Now, the intervals are totally ordered, as shown in Fig. 3c. 
Querying, e.g., the relation between intervals A and D, the path between A and B (A-B-C-D) is 
found. All noncontiguous members of the unambiguous before/meets chain being (by the chain 
definition) related by [<], the answer is A — [<] — > D. 




Fig. 3 An example. 



3 Truth maintenance 

Since a straightforward application of the time reasoning is in the planning domain [3] , 
time reasoning assumptions have to be retractable. Another potential application, qualitative 
reasoning about physical systems ([4], [7], [13] etc.), requires facilities for changing assumption 
sets easily. Obviously, some kind of nonmonotonicity must be introduced. 



In the time reasoner of Vilain [12], whole transitivity table based inferences were 
explicitly stored for truth maintenance operations. In the next section, a more concise 
representation of dependencies will be presented. 



3.1 Justification structure of time event relations 

To introduce nonmonotonicity into a temporal inference system, we have to identify 1) 
elementary pieces of data and 2) justifications. 

The elementary piece of data, belief in which is to be manipulated, can be formulated 
as "exclusion of a single elementary relation between intervals I and J”. For example, the 
semantics of I — [<,m] — > J is "between the intervals I and J, the relation before or the relation 
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meets are possible”. In other words, ”the relations before and meets are not excluded while all 
other relations are excluded”. There may be several justifications for this elementary piece of 
data; if there are none, the relation is ” possible”. 

Justifications are provided by the transitivity table, or better to say by transitions. E.g., 

I — [d,o] — > J — [mi] — > K results in I — [d,di,fi,o] — > K, i.e., it justifies the exclusion of 
{<,>,oi,m,mi,s,si,f,=}. In terms of our elementary pieces of data, the conjunctive exclusion of 
{<,>,di,oi,m,mi,s,si,f,fi,=} between I and J and of {<,>,d,di,o,oi,m,s,si,f,fi,=} between J and K 
justifies the exclusion of all elementary relations between I and K from {<,>,oi,m,mi,s,si,f,=}. This 
is the conjunctive form of justifications, typical for the most truth maintenance systems. 

However, for external assumptions to be retractable, it is sufficient to store the interval 
node identifier, the transition over which justifies an exclusion. For example, if excluded relations 
between A and B and those between B and C exclude A before C, B is stored as a justification for 
the exclusion of before between A and C. This justification is revised after every modification of the 
relation between A and B. An elementary relation, the justification set of which is empty, is believed 
to be " possible”. 

An additional problem for the nonmonotonicity results from the dynamic nature of the 
network. The network of time event nodes being dynamically modified, it must be guaranteed that 
no information is lost, not only in terms of the constraints, but also in terms of their justifications. 
So an explicit connection can be deleted only if it is completely justified by the nodes lying on the 
chain segment connecting them. If the connection is reestablished, the justifications can be fully 
reconstructed. 

Note 4 : For qualitative reasoning and problem solving applications, it would be tempting 
to use an assumption-based TMS [4], [5], [6]. However, there are two essential obstacles: 

1) The ATMS implies considering all possible contexts (external assumption sets) 
simultaneously. This makes any genuine reduction of the relation network impossible, 
since the membership in a transitive chain is itself a consequence of some external 
assumptions and thus a hypothesis whose ultimate validity is never determined. In other 
words, the transitive chain construction can take place only in some ’’currently believed 
environment” which is a direct antithesis to the ATMS concept. 

2) The transitivity table based justifications are not ’’minimal”. From the 23 conjunctive 
exclusions of our previous example, some are superfluous. E.g., to exclude I < K, 
exclusion of I < J suffices (with exclusions between J and K left unmodified). 
Theoretically, it would be possible to determine the ’’complete” set of ’’minimal” 
exclusion justifications as all minimal subsets of the current antecedents which are 
sufficient to justify the given exclusion. Unfortunately, I have found no reasonably fast 
algorithm for doing it. In an interval based time reasoning system, a (nonminimal) 
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justification for an exclusion, as it results from the transitivity table, may have up to 24 
antecedents (= data nodes) . A minimal justification typically requires only one or more 
relatively small subsets of these antecedents. To find all minimal justifications by M brute 
force”, all 2**24 possible subsets would have to be tested. That is why nonminimal 
justifications have to be put up with. However, nonminimal justifications have strong 
negative impact on the quality of ATMS based inferences, see [6]. 



3.2 The nonmonotonic algorithm 

There are two basic system functions: constraint insertion and constraint retraction. 
Since the constraint propagation part of the algorithm is similar for the both functions, an additional 
two-valued argument Op (with values ins and del) is introduced. For an external assumption (set of 
one or more constraints) to be retractable, it must be given a unique identifier, which serves as an 
external justification (Just). Algorithm 1 underlies the following modifications: 

Step 1:1) Updating a relation, additional justifications are added or deleted, from which 
all admissible relations are derived (as those with empty exclusion justification set). During a 
retraction, a relation is put into the chaining queue if it is no more a member of the chain. 2) The 
node by the way of which a constraint (using the transitivity table) came about, becomes the 
justification for this constraint. 

Step 2:1) The deletion of an explicit connection R(i,j) is performed only if all its 
relations are completely justified by the nodes from the chain segment between them. 2) 
Retracting a constraint, for each relation in the chaining queue, the sets SB and SA are defined 
(as in the insertion case). All missing "cross connections” between them are then reestablished. 

Algorithm 2 : 

modify _rel( Op,i,j, NewRel) 
update _rel (Op, i,j, NewRel) ; 

processjqueue (constraint, constraint _propagation(Op)); 
process_queue (chaining, chaining j oropagation(Op) ) ; 

with 

update _rel (ins ,r1 ,r2 , NewRel , Just) 

J(r1 ,r2) ^-modify Justification (J (rl ,r2) , NewRel, Just); 

H*-possible_rels (J (rl ,r2) ) ; 

if not H=R(r1,r2) then add_to_queue (constraint, r 1 ,r2); 

if HdCR & not R(r1 ,r2)dCR then add Jo jqueue (chaining, rl ,r2); 

R(r1,r2)*-H; 

upda tejei (del,r1,r2, NewRel, Just) 

J(r1 ,r2) ^-modify Justification (J(r1 ,r2) , NewRel, Just); 

H+-possible_rels(J(r1 ,r2)); 

if not H=R(r1,r2) then addJo_queue(constraint,r1,r2); 

if not HdCR & R(r1,r2)dCR then addJo_queue(chaining,r1,r2); 

R(r1 ,r2)+-H; 
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constraint propagation(Op,i,J) 

For each k such that triangle(lj,k) do 

begin 

update jrel (Op, k,j, transitions (R(k,l) ,R(i,J)) ,1) ; 
update jel (Op, f,k, transitions (R (i,j) , R (j,k)) ,j) ; 

end 

chaining propagation (ins,l,j) 
if in_chain(l,j) then del _seif_cont connection (i,j); 

else 

begin 

For each k such that before(k,l) do 

del jselfjcont connection (k,J) ; 

For each / such that before(j,l) do del _self_cont connection ( i,l) ; 

For each k,l such that before(k,i) & before(j,l) do 
del _self_c°nt connection (k,l) ; 

end 

chaining propaga tion (del, i,j) 

For each k such that before(k,i) do add _self_c°nt connection (k,j); 

For each / such that before(j,l) do add_self_cont_connection ( i, I) ; 

For each k,l such that before(k,i) & before(j,l) do add _seif _c°nt connection (k ,i) ; 



Additional auxiliary functions: 

- The function modify Justification ( Justifications, NewCon, id Just) returns Justifications 
modified by the additional constraint NewCon. The exclusions of all elementary relations 
not contained in NewCon are additionally justified by the event identifier idJust. If some 
justifications by this identifier are already present, they are substituted by the new ones. 

- The function possible_rels(Just) returns the set of basic relations which are not excluded 
by Just, i.e., those with empty exclusion justification set. 

- The function del _self jzont connection (i,j) deletes an explicit connection only if it is 
completely justified by the nodes lying on the chain between / and j. If it is not the case, 
all justifications by the nodes lying on the chain are substituted by the chain identifier. 
Otherwise, these justifications would not be correctly updated if the intermediate chain 
segment would be later modified. Justifications of adjacent nodes based on "triangles” 
containing the deleted connection are deleted, too. 

- The function add_seif_c° nt joonnection(i ,}) restores an explicit connection if there is no 
path between / and J, and defines its constraints using all existing full triangle 
connections. If such a connection already exists (as a consequence of justifications 
from outside of the chain segment between / and j) , the chain identifier is removed from 
the justification. 

Example 2 (Continuation of Example 1) : Let us denote the initial assumption A — [<,m] 
— > B, with al, C — [<] — > D with a2, and A — [<,o,s] — > C with a3. The exclusion justification 
lists for the individual elementary relations are given in Tab. 1 . 
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Exclusion of Relation 





(A.B) 


(A.C) 


(A.D) 


(B,c) 


(B.D) 


(C.D) 


< 


[] 


[] 


[] 


[] 


[] 


[] 


> 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


d 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


di 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


o 


[al] 


[] 


[C] 


[] 


[] 


[a2] 


oi 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


m 


[] 


[a3] 


[C] 


[] 


[] 


[a2] 


mi 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


s 


[al] 


[] 


[C] 


[] 


[] 


[a2] 


si 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


f 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


fi 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 


= 


[al] 


[a3] 


[C] 


[] 


[] 


[a2] 



Tab. 1 Initial justifications. 

We can observe that the constraints on (A,C) and (C,D) have been propagated to 
constrain (A,D), whose relation exclusions are therefore justified by C. Now, imposing the external 
constraint B — [<,m] — > C, denoted as a4, the justifications are modified (see Tab. 2). 

Exclusion of Relation 





(A,B) 


(A,C) 


(A,D) 


(B.C) 


(B.D) 


(C,D) 


< 


[] 


[] 


[] 


[] 


[] 


[] 


> 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


d 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


di 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


o 


[al] 


[B] 


[B.C] 


[a4] 


[C] 


[a2] 


oi 


[all 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


m 


[] 


[a3,B] 


[B,C] 


[] 


[C] 


[a2] 


mi 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


s 


[al] 


[B] 


[B,C] 


[a4] 


[C] 


[a2] 


si 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


f 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


fi 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 


= 


[al] 


[a3,B] 


[B,C] 


[a4] 


[C] 


[a2] 



Tab. 2 Justifications including assumption a4. 

Obviously, the explicit connection (A,C) cannot be discarded, since it is justified, in 
addition to the chain justification by B, externally by assumption a3. Since the chain segment 
between A and C may be modified through future constraints by insertion of, say, interval AA 
between A and B, the justification of (A,C) would be incomplete (omitting the justification by AA). 
(This incompleteness would result from the fact that the constraint propagation is performed only 
on complete triangles, and (A.AA.C) would not be complete because of missing connection 
(AA,C) .) . So all chain justifications, or B, in our case, are substituted by the chain identifier, say ch 
(see Tab. 3). 
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Exclusion of Relation 





(A.B) 


<A,C) 


- 


(B.C) 


- 


(C.D) 


< 


[] 


(] 


- 


[1 


_ 


[) 


> 


[all 


[a3,ch] 


- 


[•4] 
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Tab. 3 Justifications after simplifying the relation network. 

The deletion of, e.g. f the assumption a2, would result in reestablishing the connections 
(B,D) and (A,D) . 



4 Computational effectiveness 

It is very difficult to estimate generally how far the relation network will be reduced using 
transitivity. It will always depend on how much is actually known about the ordering of the events. 
The extreme cases, for N events, are total ordering (N-1 explicit relations) and no ordering 
(N*(N-1)/2 relations, as in the Allen's basic algorithm). 

Intuitively, the following observations seem to be plausible: 

Extending the time scope in consideration, the number of other events whose 
before/after relations to an individual event are unspecified remains approximately constant, so 
that there is a linear increase of the number of explicit relations with a growing number of events. 

Refining the observation of the world within the same time scope, additional ordering 
may be introduced by additional constraints resulting from these refined observations. Also, the 
number of explicit connections may be reduced using increased number of containment relations. 
However, a linear function, as in the previous case, can hardly be expected. 

Since both extending the time scope and refining the observation will frequently occur 
simultaneously, a slightly overlinear increase can be expected, a substantially better situation than 
in the case of an unreduced relation network. 

An attempt to assess the efficiency gain experimentally was made by generating the 
references randomly: for an additional event X, two events Y and Z (Z not before Y) were 
randomly selected, and Y before X, X before Z was asserted. The results are given in Tab. 4. The 
total number of explicit connections, which indicates the storage requirements, is decomposed (in 
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parentheses) into the number of before/after relations and the number of unspecified relations. 



Events Relations 

Allen’s basic alg. basic alg. TMS-based alg. 



10 


45 


(43/2) 


12 


(10/2) 


16 


(14/2) 


20 


190 


(154/36) 


61 


(25/36) 


70 


(34/36) 


40 


780 


(705/75) 


124 


(49/75) 


149 


(74/76) 


80 


3160 


(2171/989) 


1099 


(110/989) 


— 





Tab. 4 Computational experience. 

Obviously, the number of explicit relations has been substantially reduced, compared 
with Allen’s basic algorithm. The growth of the number of before/after relations is nearly linear. 
Unfortunately, this simple random test procedure was not able to show that the growth of the total 
relation number is of a polynomial order substantially less than 2 (2 being the upper level) . There 
was no means to force the events into a "reasonably small” chain segment, i.e., to ensure that 
the randomly chosen events Y and Z are "reasonably near to each other” on the chain. So there 
were many long parallel branches in the chain, the "cross connections" between whose members 
remained explicit (the second figure in each parentheses pair). However, a real world example 
would "force" a single "backbone" of the transitivity chain graph (since only a single time line 
does really exist). Thus the efficiency gain has been probably underestimated. 

5 Further research 

From the possibilities for a further development of the algorithm presented, the following 
two seem to be particularly interesting: 

- Considering several chain types simultaneously, "synergy effects" of several chain 
types can be investigated. For example, the top member of the containment chain 
being simultaneously the member of the before/meets chain, all bottom members of 
the containment chain are in the same relations to the before/meets chain as the top 
member, so that these relations do not have to be explicit. (In the present algorithm, 
they are explicit.) Such a representation would be less redundant and more natural than 
the present one. 

- The possibility of using an ATMS-like inference system would be, as stated before, very 
tempting, particularly for planning and qualitative modelling applications. The both main 
problems, the assumptions concerning the transitivity chain membership and the 
nonminimality of the transitivity table based justifications should be further investigated. 

6 Conclusion 



We have presented a way the transitivity of certain temporal relations can be used for 
increasing the efficiency and the cognitive transparency of temporal representations without 
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sacrificing the expressive power of the relation network model. The constraint propagation 
algorithm has been extended to maintain a kind of dynamically changing relation network, the 
transitive chains. Although the intended application is a temporal reasoner based on the 1 3 basic 
qualitative interval relations of J. Allen, the algorithm as well as the most of the theoretical and 
conceptual observations of this paper can be applied to any other set of mutually exclusive 
elementary time event relations (e.g., a time point based algebra, as proposed in [11]). It is 
difficult to estimate the efficiency gain through the algorithm, which varies strongly from case to 
case. However, some typical applications let us expect as weir a substantial reduction of the 
absolute number of relations to be considered explicitly as their slightly overlinear increase with the 
number of events considered. 

A nonmonotonic extension of the basic algorithm has been implemented, which is of 
crucial importance for planning or qualitative modelling applications. We have investigated the 
justification structure of the transitivity table based interval algebra as well as the impact of the 
dynamical nature of our relation network on the nonmonotonic algorithm. 
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Wissensbasierte Entscheidungsunter Stützung 
in der Anästhesie mit dem AES 



H. Klocke, Th. Schecke, M. Jeusfeld, G. Rau 

Helmholtz-Institut für Biomedizinische Technik, RWTH-Aachen 

U. Hatzky, G. Kalff 

Abteilung für Anästhesiologie, RWTH-Aachen 

Zusammenfassung: Die Aufgaben des Anästhesisten bei Operationen in 
der Herzchirurgie sind vergleichbar mit komplexen Prozeßführungsaufgaben wie 
sie aus dem industriellen Bereich bekannt sind. Zu seiner Unterstützung wird 
hier ein wissensbasiertes Anästhesie-Entscheidungsunterstützungs-System, das 
AES, entwickelt. Der Zugriff auf die Funktionen der Entscheidungsunter- 
stützung erfolgt über ein allgemeines Anästhesie-Informationssystem (AIS) 
mit einer hochinteraktiven, ergonomisch gestalteten Mensch-Maschine- 
Schnittsteile. Die Wissensakquisition wird durch eine formale Sprache zur 
Beschreibung des Expertenwissens unterstützt. Die Sätze dieser Sprache sind 
in natürlicher Sprache formulierten Sätzen sehr ähnlich, sie lassen sich 
aber in prädikatenlogische Formeln transformieren. 

1 Einleitung 

Komplizierte operative Eingriffe können mit einer hohen Belastung 
des Patienten durch die Narkose verbunden sein. Um diese Belastung auf ein 
Minimum zu reduzieren, sind immer verf einertere Anästhesiemethoden und 
-techniken sowie wirksamere Medikamente entwickelt worden. Diese 

Verbesserungen für den Patienten erhöhen allerdings drastisch die 

Anforderungen an den Anästhesisten, insbesondere an die Qualität seiner 
Überwachungstätigkeit und seiner Entscheidungen. Sein Aufgabengebiet 
Überwachung und Steuerung des Patientenzustandes - besitzt große Ähnlichkeit 
mit komplexen Prozeßführungsaufgaben zur Beherrschung von technischen 
Systemen, einige Autoren vergleichen seine Tätigkeit auch mit der eines 
Piloten im Cockpit /7/. 
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Um den Anästhesisten bei diesen Aufgaben zu unterstützen, ist am 
Helmholtz- Institut für Biomedizinische Technik in Aachen unter Mitwirkung 
der Abteilung für Anästhesiologie ein Anästhesie-Informationssystem (AIS) 
konzipiert und realisiert worden, das ihm die (vorgeschriebene) 
Protokollierung und Überwachung der Patientenparameter erleichtert und durch 
eine geeignete Darstellung der relevanten Informationen eine erste 
Entscheidungshilfe bietet. Eine besondere Bedeutung gewinnt hierbei die 
geeignete Gestaltung der hochinteraktiven Schnittstelle zwischen Anästhesist 
und Computer /10, 11, 16, 17/. Dieses System ist im Operationssaal im 
"Feldtest" erprobt und weiterentwickelt worden. 

Darüberhinaus ist eine weitere Unterstützung durch die Integration 
von Wissen aus ausgewählten Gebieten der Anästhesie in ein derartiges 
Informationssystem sinnvoll. Dies ist als Funktionsmuster mit Hilfe von 
Methoden aus der Künstlichen Intelligenz bei uns als Anästhesie-Entschei- 
dungsunterstützungs-System (AES) realisiert worden /12/. 

Der wissensbasierte Ansatz zur Entscheidungsunterstützung in der 
Medizin ist vor allem durch das klassische Expertensystem MYCIN /19/ bekannt 
geworden. MYCIN wurde zur Diagnose von Infektionskrankheiten entwickelt und 
als Konsultationssystem konzipiert. Die Weiterentwicklung führte zu EMYCIN, 
einer Expertensystem-Shell ohne bereichsspezifisches Wissen. Mit Hilfe von 
EMYCIN sind unter anderem 2 weitere medizinische Expertensysteme entwickelt 
worden: PUFF /l/ zur Interpretation von Lungenfunktionstests und VM /5/ zur 
Überwachung der maschinellen Beatmung von Patienten auf der Intensivstation. 

In neuerer Zeit sind zahlreiche problembereichsunabhängige 
Expertensystem-Shells vorgestellt worden (z.B. 0PS5, Twaice, Babylon, KEE 
etc.), die zum Teil aus Expertensystem-Shells für bestimmte Anwendungsge- 
biete hervorgegangen sind (z.B. MED2 /15/). 

Das im folgenden beschriebene System AES arbeitet nicht wie z.B. 
MYCIN als Konsultationssystem, sondern als Monitoring-System ähnlich VM, im 
Gegensatz zu diesem wird es nicht auf der Intensivstation, sondern im OP für 
die Anästhesie bei kardiochirurgischen Eingriffen eingesetzt (Bild 1). 
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2 Spezifische Randbedingungen und Anforderungen 

Besondere Bedingungen für eine wissensbasierte Entscheidungsunter- 
stützung ergeben sich aus dem Einsatz im OP: 

a) Während einer Herzoperation durchlaufen die meßtechnisch erfaßten 
Parameter des Patienten (div. Blutdrücke, Puls, Temperaturen, Blutwerte 
etc.) sehr unterschiedliche, zum Teil nicht mehr physiologische Zustände, 
die abhängig vom Operationstyp und von der Operationsphase nach 
unterschiedlichen Kriterien beurteilt werden. Bereits akquiriertes Wissen in 
bestehenden Expertensystemen für weniger extreme Situationen (z.B. 
Intensivstation) ist nur sehr begrenzt anwendbar. 

b) Die moderne Anästhesie verlangt in der Therapie sorgfältig dosierte und 
aufeinander abgestimmte Kombinationen von Medikamenten sowie die gezielte 
Anwendung medizintechnischer Geräte. Eine Entscheidungsunterstützung muß 
deshalb sowohl Wissen über komplexe logische Zusammenhänge enthalten wie 
auch - aus Kl-Sicht scheinbar triviales - Formel-Wissen. Der Benutzer muß 
die Möglichkeit haben, sich einen Überblick über das jeweils verwendete 
Formel-Wissen zu verschaffen und dieses zu kontrollieren. 

c) Während der Operation hat der Anästhesist häufig keine Zeit, in 
Terminalsitzungen den Informationsbedarf eines Expertensystems zu befriedi- 
gen, da er sich vor allem auf Überwachung, Beurteilung und Steuerung des 
Patientenzustandes konzentrieren muß, Entscheidungen müssen u.U. schnell 
getroffen werden. Eine wissensbasierte Entscheidungsunterstützung hat wenig 
Erfolg, wenn sie den Anästhesisten durch aufwendige Interaktion zusätzlich 
belastet. Ein Konsultationssystem scheidet demnach aus. Daher ist es 
sinnvoll, möglichst nur die Informationen auszuwerten, die ohnehin 
protokolliert werden müssen. Die Eintragung sollte nicht aufwendiger sein 
als die bisherige Protokollierung von Hand. 

d) Die Ergebnisse der Entscheidungsunterstützung müssen schnell zur 
Verfügung stehen. Wenn die zur Verfügung stehenden technischen Möglichkeiten 
begrenzt sind (im vorliegenden Fall ein 16/32-Bit-Rechnersystem CADMUS 
9230), dann sind dem Umfang und der Tiefe der Wissensbasis vergleichsweise 
enge Schranken gesetzt. 



e) Die Experten sind stark in die klinische Routine eingespannt und haben 
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erfahrungsgemäß wenig Zeit für die Wissensakquisition, Um ihre knappe Zeit 
intensiv zu nutzen, ist es sehr hilfreich, wenn eine Sprache zur Verfügung 
steht, die von den beteiligten Kommunikationspartnern (Experten, 
Wissens-Ingenieur, Rechner) gleichermaßen verstanden wird. Auf der Grundlage 
von allen verstandener Formulierungen lassen sich Verfälschungen der Inhalte 
auf dem Weg vom Experten über den Wissens-Ingenieur zum Rechner eher 
vermeiden. 

3 Mensch-Maschine-Schnittsteile 

Um der Anforderung c) gerecht zu werden, arbeitet die 
wissensbasierte Entscheidungsunterstützung eng mit einem allgemeinen 
Anästhesie-Informationssystem, dem AIS, zusammen (Bild 2). 

Das AES stellt sich für den Benutzer als Komponente des AIS dar, 
insbesondere wird es über dieselbe interaktive Mensch-Maschine-Schnittsteile 
bedient. Dieses Informationssystem unterstützt den Anästhesisten bei der 
Überwachung des Patientenzustandes und bei der Protokollierung des 
Anästhesieverlaufs. Dazu werden bestimmte Meßwerte des Patienten (Blutdruck, 
Puls, etc.) automatisch erfaßt; die Maßnahmen des Anästhesisten 
(Verabreichung von Medikamenten, Steuerung der Beatmung, usw. ) sowie 
bestimmte Operationsereignisse (Intubation, Bypassbeginn etc.) werden von 
Hand eingetragen. Die Eingabe erfolgt über einen berührempfindlichen 
hochauflösenden Farb-Rastergraf ik-Bildschirm, dabei werden die betreffenden 
Informationselemente in Form von virtuellen Tasten und Analog-Schiebern 
direkt manipuliert /20/ - eine Tastatur mit Kenntnis der entsprechenden 
Kommando-Sprache oder Menü-Strukturen ist nicht erforderlich. Die Gestaltung 
dieser Mensch-Maschine-Schnittsteile, insbesondere der gezielte Einsatz der 
Farbkodierung von Information, ist in /10,11/ eingehend beschrieben worden, 
sie wird im folgenden nur kurz skizziert. 

Das AIS präsentiert sich in Form von Informationsseiten, die alle 
nach demselben Schema aufgebaut sind (Bild 3). Der Kern besteht aus den 
Fenstern zur Darstellung der Vitalparameter und der Beatmung. Um diese 
Fenster herum gruppieren sich in Form von virtuellen Tasten eine 
"Begriffsleiste" (links) und eine "Funktionsleiste" (unten). Über dem 
Vitalparameterfenster befindet sich ein Meldefenster. Die Begriffsleiste 
enthält in den virtuellen Tasten die Bezeichnungen der zu protokollierenden 
Maßnahmen und Aktionen, Einträge werden als Fähnchen über der Zeit den 
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Kurven der Vitalparameter überlagert. 

Bild 4 zeigt das Interaktionsschema zur Protokollierung der 
Verabreichung von 0.1 mg Fentanyl /10/: 

1. Das Medikament Fentanyl wird durch Berühren der entsprechenden Taste 
aktiviert. 

2. Soll die Eintragung nicht zur Echtzeit erfolgen, dann wird die virtuelle 
Zeitlinie auf den entsprechenden Zeitpunkt geschoben. 

3. Die Dosierung 0.1 mg wird auf dem virtuellen Mengenschieber in der 
Funktionsleiste eingetragen. 

4. Durch Betätigen der Taste "Fertig" wird die Transaktion abgeschlossen. 

Das AES liefert über dieses Informationssystem hinaus zusätzliche 
Informationen, es stützt sich bei der Anwendung seines Wissens aber nur auf 
die Informationen, die dem AIS ohnehin bekannt sind. Der Benutzer wird also 
nicht durch zusätzliche Eingaben beansprucht. 

Die Ausgaben des AES werden ebenfalls in das AIS integriert: 
Diagnosen und Therapie-Empfehlungen werden im Meldefenster dargestellt, 
Dosierungs-Empfehlungen für die Medikamente erscheinen als Zahlen innerhalb 
der entsprechenden Begriffs-Tasten. 

Der Benutzer kann sich die Ergebnisse des AES erklären lassen. Dazu 
berührt er das Meldefenster und aktiviert damit das Fenster zur 
Erklärungskomponente im unteren Teil der Informationsseite (Bild 5). Mit dem 
Pfeil kann man sich durch die logischen Komponenten der Meldung (Diagnosen, 
Therapie-Empfehlungen) durchtasten und durch Betätigen der Taste "???" die 
Erklärung für die angewählte Komponente anfordern. Dargestellt wird dann die 
Diagnose- oder Therapie-Regel, die zu der Komponente geführt hat, sowie der 
Zustand der zur Herleitung benutzten Meß- und Hilfsgrößen. Derzeit lassen 
sich nur die Diagnosen und Therapie-Empfehlungen erklären, weitere 
Hilfsregeln noch nicht. 

4 Wissensstruktur 

Im wesentlichen umfaßt das AES heuristisches Wissen zur Bewertung 
der Elektrolyte und des Säure-Basen-Status des Blutes. Zu diesem 
medizinischen Problemkreis wird von Patil /14/ für die Innere Medizin ein 
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sehr tief und umfangreich angelegter Ansatz zu einem komplexen kausalen 
Modell verfolgt. Da allerdings für den Einsatz im OP anderes Spezialwissen 
als in der Inneren Medizin herangezogen wird (vgl. Randbedingung a) und der 
Anästhesist nicht durch aufwendige Kommunikation mit dem Entscheidungsunter- 
stützungs-System belastet werden soll (vgl. Randbedingung c) ist dieser 
Ansatz in der hier dargestellten Situation nicht realisierbar. 

Stattdessen wird ein einfacheres Modell zugrunde gelegt. Die 
während der Operation ermittelten Blutwerte werden zunächst bewertet und 
bestimmte Ergebniskombinationen führen zu Diagnosen. Im Kontext der bisher 
getroffenen Maßnahmen und weiterer Patientendaten (wie Gewicht, Alter etc.) 
ergeben sich Therapie-Empfehlungen, zum Beispiel die Einstellung des 
Respirators (Beatmungsgerät) oder Vorschlag und Dosierungsempfehlung 
bestimmter medikamentöser Maßnahmen. Die Monitoring-Aufgabe verlangt dabei 
einen datengesteuerten Ablauf, getriggert durch die Eintragungen neuer 
Werte. 



Bewertung und Dosierungsempfehlungen beruhen nicht nur auf 
logischen, sondern auch auf numerischen Zusammenhängen, die die Integration 
des eingangs erwähnten Formel -Wissens verlangen. 

Die Modellierung des AES -Wissens umfaßt die folgenden Strukturelemente: 

- Parameter : Als Parameter werden im folgenden alle Informationen 
bezeichnet, die vom AIS erfaßt (s.o.) und von der Entscheidungsunterstützung 
ausgewertet werden. 

- Diagnose- und Therapie-Regeln; Die Ergebnisse der Diagnose- und 
Therapie-Regeln erscheinen als Meldungen im Meldefenster. 

- Hilfsregeln : Mit den Hilfsregeln werden Zwischenergebnisse gefolgert, die 
in den Diagnose- und Therapie-Regeln sowie in anderen Hilfsregeln weiter 
verwendet werden. Die Ergebnisse erscheinen aber nicht als explizite 
Meldungen. 

- Bereichsdefinitionen : Die Meßwerte werden relativ zu bestimmten 
symbolischen Charakterisierungen (Wertebereiche) bewertet. Diese Bereiche 
können ihrerseits von weiteren Parametern und Zwischenergebnissen abhängen. 

- Definitionen von Hilfsparametern: In Abhängigkeit vom Kontext erhalten 
Hilfsparameter einen nach einer Formel zu berechnenden Wert, der seinerseits 
in weitere Wissenselemente einfließt. 
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- Definitionen der Gültigkeitsdauer; Manche Meßwerte sind nach ihrer 
Erfassung nur eine bestimmte Zeit gültig; wenn sie danach nicht erneut 
übermittelt werden, dürfen aufgrund der alten Werte keine Schlußfolgerungen 
mehr gezogen werden. 

- Unqültiqkeitsbedingunqen ; Einige therapeutische Maßnahmen des Anästhe- 
sisten beeinflussen bestimmte Meßwerte sehr schnell relativ zu ihrer 
Abtastperiode, so daß nach einem entsprechenden Eintrag neue Meßwerte 
abgewartet werden müssen, bevor sie in weiteren Folgerungen verwendet werden 
dürfen. Z.B. beeinflußt eine Veränderung der Respirator-Einstellung sofort 
den Sauerstof fgehalt des Blutes (P02~Wert), der nur in bestimmten Abständen 
im Labor ermittelt wird. 

- Dosierungsempf ehlunqen , Sie werden abhängig vom Patientenzustand aus den 
Patientendaten (wie Alter, Gewicht) berechnet. Die Ergebnisse gelangen 
allerdings nicht zum Meldefenster, sondern werden direkt in die 
Begriffs-Tasten der entsprechenden Maßnahmen eingetragen. 

Der Faktor Zeit spielt in zwei Punkten eine Rolle: Einmal werden 
die Werte einiger Parameter nach Ablauf bestimmter Zeitintervalle ungültig 
(Definition einer Gültigkeitsdauer). Weiterhin können bestimmte Situationen 
erst dann für Entscheidungen relevant werden, wenn sie eine Zeit lang 
bestanden haben (Verlaufsbeurteilung). 

5 AES/L: Sprache zur Beschreibung des Wissens 

Eine formale Beschreibung des so strukturierten Anästhesie-Wissens 
ist für die Repräsentation auf dem Rechner erforderlich. Dazu wurde die 
Sprache AES/L entwickelt, die folgenden Anforderungen genügt: 

1. Mit den zur Verfügung gestellten Konstrukten der Sprache AES/L lassen 
sich die skizzierten Zusammenhänge adäquat beschreiben. 

2. Die Sätze dieser Sprache ähneln in natürlicher Sprache formulierten 
Sätzen, so daß sie als gemeinsame Kommunikationsbasis zwischen Mediziner und 
Wissens-Ingenieur dienen. 

3. Es handelt sich um eine formale Sprache, die sich maschinell übersetzen 
läßt. 
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Im folgenden werden die Konstrukte dieser Sprache anhand einfacher 
Beispiele kurz vorgestellt , die formale Definition der Syntax und Semantik 
findet sich in /12/. 

Das erste Beispiel zeigt das allgemeine Format der Regeln: 

diagnoseregel 14 heisst 
wenn 

1 P02' < '02-Grenzwert • 
dann 

"Hypoxie". 

Die Klassifizierung der Regeln nach Diagnose-, Therapie- und 
Hilfsregeln erleichtert die Strukturierung der Wissensbasis. Als Folgerung 
ergibt sich ein Text, der in den Bedingungsteil weiterer Regeln einfließen 
kann. Darüberhinaus werden die Folgerungstexte der Diagnose- und 
Therapie-Regeln an das AIS gesendet und im Meldefenster dargestellt. Der 
Hilfsparameter ' 02 -Grenzwert ' ließe sich wie folgt über eine Formel 

definieren: 

'02-Grenzwert' := 108.86-0.26* 'Alter 1 

-7.30* ( 'Gewicht' )/( 'Laenge' -1 )-15.10. 

(Gewicht in kg, Länge in cm). 

Die anzuwendende Formel kann von Bedingungen abhängig gemacht werden: 
wenn 

'Geschlecht' = "weiblich" 
dann 

'02-Grenzwert ' : = 108 .86-0 . 26* ' Alter ' 

-7.30*( 'Gewicht' )/( ' Laenge '-1 ) -15.10. 

Wie die folgende Therapieregel zeigt, können auch in die "Ausgabe" 
( "dann"-Teil ) einer Regel Formeln integriert werden: 
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therapieregel 23 heisst 
wenn 

"Hyperkaliaemie" und 
'Gewicht' >=20 und 

"LASIX ist bereits eingetragen worden" und 
"metabolische Azidose" 
dann 

"Gabe von ", abs ( 'BE ' ) *10, " ml NaBic 8.4% ?". 

Zur Charakterisierung des zeitlichen Verlaufs steht das Konstrukt 
"seit N min" zur Verfügung: 

diagnoseregel 25 heisst 
wenn 

'mittl .Blutdruck ' ist unter 'normal fuer HLM ' seit 5 min 
dann 

"mittl .Blutdruck zu niedrig: ", 'mittl .Blutdruck ' . 

Die Beurteilung von Parametern relativ zu charakteristischen 
Bereichen (wie "normal fuer HLM" - HLM: Herz-Lungen-Maschine) wird sehr 
häufig in Bedingungen eingesetzt. Diese Bereiche lassen sich z.B. wie folgt 
definieren : 

wenn 

"Patient ist an Herz-Lungen-Maschine" 
dann 

'mittl .Blutdruck ' ist 'normal fuer HLM' innerhalb 40 bis 90. 

Die beiden folgenden Sätze sind Beispiele zur Formulierung von 
Dosierungsempfehlungen : 

empfohlen 'FENTANYL' := 0.004 * 'Gewicht'. 
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wenn 

'Plat. druck' > 20 und 'Reet. Temp.' > 37.50 
dann 

empfohlen 'Min.Vol.' := (0.0672 * 'KO' * 'Energieverbrauch' + 

•Frequenz' * (0.05 * 'KO' + 0.10)) * 

(1 + 0.10 * ( 'Reet. Temp. ' - 37.50)) + 

'Frequenz' * 0.005 * ( 'Plat .druck ' - 20). 

(FENTANYL in mg, Gewicht in Kg, Plat. druck in cm H20, Reet. Temp, in grad C, 
Min.Vol. in 1/min, KO in qm, Frequenz in 1/min). 

Die oben dargestellten Gültigkeitsbeziehungen lassen sich mit den 
Konstrukten "gueltig fuer", "gueltig bis” und "ungueltig wenn" formulieren: 

'Blutdruck' ist gueltig fuer 3 min. 

'P02 ' ist gueltig bis veraendert. 

'P02' ist ungueltig 
wenn 

'Seufzer', 'I/E', 'PEEP', 'Min.Vol.', 'Frequenz', 

' Atemgase ' , ' EUPHYLLIN ' 
eingetragen wird. 

Die Sätze dieser Sprache lassen sich in prädikatenlogische Formeln 
transformieren /12/, die Ergebnisse dieser Transformation sind Horn-Klausen. 
Sie können damit auf der Grundlage einer Relation zur Bestimmung der 
aktuellen Parameter-Werte von einem Laufzeitsystem in effektiver Weise 
interpretiert werden. 

6 Realisierung 

6.1 Übersetzung 

Die somit mögliche Lesart der Sätze in AES/L als Horn-Klausen legt 
die Übersetzung in PROLOG nahe. Die Syntax von AES/L ist so gestaltet, daß 
jeder gültige Satz einen PROLOG-Term darstellt. Durch eine geeignete 
Definition der Schlüsselworte wie "wenn”, "dann", "ist unter", "ist gültig" 
als PROLOG -Operatoren ergibt sich der natürlichsprachliche Charakter der 
Sätze. Da PROLOG einen recht mächtigen Mechanismus zur Unifizierung von 
Strukturen zur Verfügung stellt, läßt sich mit relativ geringem Aufwand ein 
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Übersetzer in PROLOG entwickeln. 

Während der Übersetzung wird ein Abhängigkeitsgraph aufgebaut und 
ausgewertet, so daß für jeden Parameter angegeben werden kann, welche 
Folgerungen (Regeln, Hilfsparameter, Definitionen etc.) dieser Parameter 
beeinflußt. Dabei werden zirkuläre Abhängigkeiten gefunden und als Fehler 
gemeldet. 



6.2 Lauf zeit system 

Die Anwendung dieses Wissens ist dann eine Kombination aus 
Vorwärtsverkettung und "Backtracking": Bei jeder Eintragung von Parametern 
in das AIS werden auf der Basis des ausgewerteten Abhängigkeitsgraphen die 
in Frage kommenden Diagnose-, Therapie- und Empfehlungsregeln ausgewählt 
(Vorwärtsverkettung), diese Schlußfolgerungen werden dann angestoßen. Die 
Ausführung (Beweis) einer Folgerung lehnt sich dann an den Resolutions- 
Mechanismus von PROLOG an: Um die Bedingungen einer Regel zu überprüfen, 

wird versucht, sie aufgrund anderer Regeln zu erschließen (Backtracking). 

Eine Folgerung kann nur bewiesen werden, wenn die Parameter, die in 
sie einfließen, gültig sind, d.h. wenn ihre Gültigkeitsdauer noch nicht 
abgelaufen ist und kein Parameter aufgrund einer Ungültigkeitsbedingung 
explizit ungültig geworden ist. Die dabei bewiesenen Ergebnisse (Diagnosen 
und Therapie-Empfehlungen) und Zwischenergebnisse (Hilfsparameter und 

-regeln, Charakterisierungen) werden als "Lemmata" abgelegt. Die Idee dieser 
Lemma-Generierung wurde in /8/ angeregt und um einen Mechanismus zur 
Aktualisierung der Lemmata erweitert, der auch die dynamische Berücksich- 
tigung der Gültigkeits- und Ungültigkeitsbeziehungen erlaubt. 

7 Erfahrungen und Ausblick 

Das AES umfaßt zur Zeit ein Wissen von 272 Sätzen in AES/L, das 37 
der vom AIS zur Verfügung gestellten Parameter auswertet. Zu diesen Sätzen 
gehören : 

29 Diagnoseregeln 
58 Therapieregeln 
22 Dosierungsempfehlungen 
8 Hilfsregeln 

- 155 sonstige (Definitionen von Bereichen, Hilfsparametern, 
Gültigkeitskeitsdauern, Ungültigkeitsbedingungen) 
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Mit diesem Wissensumfang genügt das AES bei den Erprobungen im OP den 
gegebenen Anforderungen an das Echtzeitverhalten (einige Sekunden nach 
Parametereintragung). Einen wesentlichen Beitrag zur Effizienz liefert die 
Lemmata-Verwaltung mit einer Trefferquote von ca. 95 %. 

Einige der befragten Experten sind z.T. mit klassischen 
Programmierkonzepten vertraut. Das dadurch geprägte algor'ithmen-orientierte 
(imperative) Modell vom Computer stand anfangs der Vermittlung der 
Mächtigkeit des wissensbasierten Ansatzes im Wege. Zur Vermittlung der 
prinzipiellen Möglichkeiten dieses Ansatzes hat sich der deklarative, 
logik-orientierte Charakter der Sprache AES/L als deutliche Hilfe erwiesen. 



Weitere Arbeiten laufen zur ergonomischen Gestaltung der Ausgaben 
des AES und zum weiteren Ausbau des AES -Wissens. 
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Bild 1 

Erprobung des 
AIS/AES im OP 




Bild 2 

Das AIS als Benutzerschnittstelle zum AES 
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Bild 3 

Schematischer Aufbau einer AlS-Informations-Seite nach /12/ 




Bild 4 Bild 5 

Interaktionsschema zur Erklärungskomponente des 

Protokollierung von 0,1 mg AES nach /12/* 

Fentanyl um 11:10 Uhr 
nach /10/. 
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Übersicht Uber das Di agnost i k -Expert ensyst em-She 1 1 ME D 2 



Frank Puppe 

Universität Hamburgs Fachbereich Informatik 
Bodenst edt st r . 16* 2000 Hamburg 50 



Zusammenfassung : Expertensysteme soLLten von Experten entwickelt 
werden. Das Di agnost i k -Expert ensyst em-Sh e l l MED2 ist ein 
im HinbLick auf diese Anforderung entworfenes Werkzeug/ in das 
typische Wi ssenss t ruk t ur i erungen/ Vorgehensweisen und Bewertungs- 
mechanismen der heuristischen Diagnostik eingebaut sind/ die 
zusammen eine höheres Abstraktionsniveau zum Aufbau einer 
Wissensbasis aLs Regeln oder Frames berei tste L Len. MED2 eignet 
sich damit für Prob L e mbe r e i c h e / bei denen die Lösungen aufgrund 
von Erfahrungswissen aus einer vorgegebenen Menge möglicher 
Lösungen ausgewähLt werden. 



1 



Ei n Lei tung 

'«uv ’v ■: t "i 



Die ErfoLge von Expertensystemen beruhen hauptsächlich auf der 
Forma L i si erung von bereichsspezifischem Wissen/ das von 
erfahrenen Experten stammt. Die UbLiche Vf i ss en s e rwe r bsme t hode 
besteht darin/ daß ein "Wi ssensi ngeni eur " sich das Wissen des 
Experten durch enge Zusammenarbeit aneignet und für das 
Expertensystem forrnaLisiert. Dieses Vorgehen ist jedoch sehr 
zeitaufwendig/ und der Erfolg hängt nicht nur von dem Experten/ 
sondern auch entscheidend von den Fähigkeiten des Wissensin- 
genieurs ab. Es wäre daher wünschenswert/ wenn der Experte sein 
Wissen möglichst selbständig - ähnlich wie beim Schreiben von Bü- 
chern - f orma l i si eren würde. Dazu werden Experten aus Zeitgründen 
jedoch nur dann bereit sein/ wenn die Wi ssensr epr äsent at i on der 
benutzten formalen Sprache ihrer eigenen hinreichend ähnlich ist. 
Die bisherigen Erfahrungen mit den Basi srepräsent at i onen wie 
Regeln/ Frames/ Constraints und Logik und ihren zugehörigen 
Kont ro L Ist rat egi en wie Forward- und Bac kwardr easoni r.g zeigen/ daß 
diese für sich keinen angemessenen Abst rakt i onsgrad darsteLLen. 
Die entsprechenden reinen und hybriden Expert ensyst emvier kzeuge 
sind daher eher für den Wi ssensi ngi ni eur als den Experten 
geeignet . 

Um einen für Experten akzeptabLen Formalismus bere i t zust e L len 
haben wir uns auf einen ProbLemtyp/ nämLich assoziative 
(heuristische) Diagnostik [Clancey 85] spezi a li si ert und 
versucht/ die Vorgehensweise von Menschen zu simulieren. Dabei 
haben wir uns zunächst am medizinischen Bereich orientiert/ da 
dieser am besten untersucht wurde (sowohL empirisch mit 
Syst emprototypen CClancey 84] als auch in psychologischen 
Studien/ z.B. CELstein 78/ Kassirer 78]). Die Konzeption von MED2 
[Puppe 86a] basiert außerdem wesentlich auf den Erfahrungen mit 
H EDI [Puppe 85] und der Übertragung und Weiterentwicklung von auf 
MED1 begonnenen Demonst rat i onswi ssensbasen im med i z i ni sch en und 
technischem Bereich ( Brust schmerz und ChoLestase [Puppe 84] bzw. 
KF Z-Kundendi enst [Borrmann 83]). Weiterhin wird es derzeitig in 
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versch i edenen externen Anwendungspro j ek t en erprobt * u.a. zur 
Prozeßdiagnostik in einer Lac k i eran Lage und bei der Gummiferti- 
giing, zur Qualitätskontrolle in Getrieben und Tur bokompr essor en * 
zur Reparaturdiagnostik bei Getrieben und zur Objekter- 
kennung bei der Pi Lzbest i mmung . Allerdings Liegen z.Z. (Dez. 86) 
noch kaum Ergebnisse vor. 

Im folgenden Abschnitt wi rd ein allgemeines ModeLL des 
diagnostischen Problem Lösens skizziert und im dritten Abschnitt 
deren Realisierung in MED2 gezeigt. Im vierten Abschnitt werden 
wichtige ergänzende Diagnostikaspekte behände Lt. Beim Aufbau 
einer Wi ssensbas i s steuert der Experte durch das AnLegen von 
Objekten und deren Charakterisierung durch Attribute die 
Anwendung der Konzepte. Abschnitt 5 gibt' ei ne knappe Übersicht 
über die Wi ssensr epräsent at i on von MED2- Eine de t a i L L i er t er e 
DarsteLLung würde den Rahmen dieser Übersicht sprengen; sie 
findet sich in [Puppe 86a* Kap. 4-3-ü. Im sechsten und siebten 
Abschnitt folgen eine kurze Diskussion und Auszüge aus einem 
Di a Logbe i spi e L mit der KFZ-Kundenwi ssensbasi s von M E D 2 * in dem 
die Fähigkeit von M E D 2 zur Auswertung von Fo Lge si t Zungen 
demonstriert wird. 



2 . Überblick über assoziatives diagnostisches Pr o blemj^^g^ 



Diagnostik (Fig. 1) beginnt mit den vom Benutzer präsent i er t en 
Hauptsymptomen. Diese Rohdaten werden zunächst zu aussagekräfti- 
geren Symptominterpretationen vorve r arbe i t e t (z.B. PuLs > 90 ==> 
Tachykardie)* bevor sie diagnostisch ausgewertet werden. Dabei 
werden entsprechend der hypothetisch -deduktiven Vorgehens weise 
zunächst in grober Weise Verdachts diagnosen generierte die dann 
genauer überprüft und schLießLich systematisch mit ähnlichen* 
Leicht verwechse Lbaren "Di f f erent i a Ldi agnosen" verglichen werden. 
Fa L Ls not wendi g * wird gezielt noch weiteren Symptomen gesucht. 

Häufig ist es schwierig* direkt von Symptomen auf Enddiagnosen zu 
schließen* deswegen versucht man zunächst* partie Lie Interpreta- 
tionen (Grobdiagnosen) zu finden* die schrittweise über einen 
diagnostischen Mittelbau verfeinert werden. Am Ende der 
Diagnostik stehen eine oder mehrere Enddi agnosen* für die 
Therpi evorsch Läge gemacht werden. Wenn nach der Durchführung der 
Therapie die anfänglichen Beschwerden nicht verschwunden sind* 
beginnt ein neuer Zyklus* wobei die zeitliche Änderung der 
Symptome und die Reaktion auf die Therapie zusätzliche 
diagnostische Hinweise Liefern. 

Eine gute diagnostische Vorgehensweise muß die vorhandenen 
Daten optimaL ausnutzen. Das bedeutet insbesondere eine Anpassung 
an den gegebenen Detaillierungsgrad der Daten und eine da ten- 
gesteuerte Auswertung des d i ag.nos t i sc h en Mittelbaus* so daß 
jede Diagnose unabhängig von ihrer SteLLung in der Hierarchie 
Ausgangspunkt der weiteren Diagnostik sein kann. 
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3. 



Diagnost i sches Prob Lern lösen in i_njD2 



In diesem Abscnitt beschreiben wir* wie die skizzierte 
Diagnosestrategie in MED2 reaLisiert ist. Die Unterabschnitte 
entsprechen Weitgehend den Phasen in Fig. 1. 

^ |Symptomer f assung] ^ 

I 

|Dat envorverarbe i 1 ung[ 

|~Ver dacht sqeneri erungl 

< "j -- 1 | v e r d a c h t s üb e r p r U f u n g| 

u Huie*** J 

l- >| p -iffe^entiaLdiagnostikl 

* , 

Therapi evorsch lag| 

- £_ 

y ^herapi e) 

iTh e r ap i e a us w i r k ung e n f- - - ?? - 

Fig. 1: Diagnostische Vorgehensweise 



3.1 



Syrnptomer f assung 



Die optimaLe Symptomerfassung Läßt sich am besten durch die 
Strategie "so genau wie nötig und mit so wenig Aufwand wie 
möglich" charakterisieren- Um eine fLexibLe Di a Logs t e uer ung 
(s. Kap. 4.1) zu errnög Li chen^ hat M E D 2 zwei Ebenen 
der Symptomerfassung: 

- Einzelne Fragen mit ihren Antworta It ernat i ven (z.B. Intensität 
und LokaLisation des Brust Schmerzes; oder Verhalten des Motors 
bei Besch Leunigung) 

- Quest i onsets/ die eine Gruppe von Fragen zusammen f assen (z.B. 
alle Fragen zum Brustschmerz oder zu Fahrfehlern) 

Die Steuerung des DiaLoges findet auf der Ebene der Questionsets 
statt: zu Beginn der Sitzung gibt der Benutzer die Questionsets 

an, die seine Beschwerden erfassen; wenn alle angegebenen 
Questionsets abgearbeitet sind* kann MED2 oder der Benutzer nach 
Bedarf weitere Questionsets seLektieren. 

Intern besteht ein Questionset aus einer Hierarchie von 

Detai Lf ragen* deren Abarbeitung rein datengesteuert ist: falls 
nötig fragt MED2 zunächst* ob der Questionset überhaupt erfragbar 
ist (z.B. ob ein Leitsymptom überhaupt vorhanden ist bzw. ob eine 
technische Untersuchung durchgeführt wurde). FaLLs die Antwort 
positiv ist* werden aLLgemeine Fragen gestellt* die in 

Abhängigkeit ihrer Antworten weiter verfeinert werden können. Der 
VorteiL der hi erarchi sehen Frage st rat egi e ist* daß unnötige 
Fragen weitgehend vermieden werden. 
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Häufig Lä(3t sich ein Symptom durch verschiedene Erhebungs- 
verfahren bestimmen^ die unt er sch i ed L i chen Aufwand erfordern und 
eine unterschiedliche Genauigkeit besitzen (z.B. eine Leberver- 
grö(3erung kann ertastet oder im Röntgenbi Ld gesehen werden). In 
MED2 kann jedes Erhe bungsver f ahr en in einem unabhängigen 
Quest i onset erfaßt werden; die optimale Auswertung wird im 
Abschnitt Verdacht slibe rprüf ung beschrieben. 



3.2 



Datenvorverarbeitung 



Manche Rohdaten eines Questionsets werden sofort bei der Symptom- 
erfassung auf gearbe i t e t (z.B. Benzinverbrauch eines Autos der 
Marke X ist 12 Liter ==> Benz i nverbrauch zu hoch; oder Puls ist 
110 und Blutdruck ist 100 ==> Schockindex ist 1.1). Solche 
einfachen Symptominterpret at ionen sind häufig cle f i n i t or i sc h * oder 
sie abstrahieren von quantitativen zu qualitativen Vierten. 
Syrnptomi nt erpre t at i onen werden in MED2 wie Symptome behände Lt mit 
dem Unterschied* daß erst er e mit Regeln aus anderen Daten 
hergeleitet werden* während letztere vom Benutzer erfragt werden. 
Der Zweck von Syrnptomi nt erpre t at i onen besteht darin* den 
eigentlichen Diagnostik prozeß vorzubereiten und zu erleichtern. 



3.3 



Verdachtsgenerierung 



Während es in k Leinen Anwendungsbereichen mögLich ist* immer a Lie 
Diagnosen zu Überprüfen* muß sich ein Problemloser in großen 
Bereichen auf die wichtigsten Verdacht sdi agnosen konzent r i e r en * 
weil er sonst sehr ineffizient arbeiten würde und zu 
einer gezielten Symptomerf assungsst rategi e unfähig wäre. Dazu 
eignet sich die Hypo t h e z i se -and -Te s t -St r a t e g i e * die spezielles 
Wissen zur Verdachtsgenerierung erfordert. Der einfachste 
Mechanismus bestände darin* daß jedes positive Symptom einer 
Diagnose diese aktiviert. Eine effizientere* aber fehLeranfälli- 
gere Strategie erhalt man* wenn die Diagnose nur durch ihre 
wichtigsten Symptome getriggert werden kann. Beide Strategien 
Lassen sich in MED2 realisieren* da die Regeln zur Bewertung von 
Diagnosen in verschiedene Typen klassifiziert werden können: 
Forward (F)* Forward&Bac kward (F&B) und Backward (B). Sie 
unterscheiden sich in zwei Eigenschaften: di agnost i sehe Bedeutung 
und Auswertungsmodus. 
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Die Generierung eines Di agnoseverdach t es ist nur mit F und 
F&B-RegeLn möglich* wobei die F-RegeLn ausschließlich der 
Verdacht sgener i erung dienen* während die F&B-RegeLn gleichzeitig 
auch die Diagnose bewerten. FaLLs die Aktivierung einen 
Schwel Lwert über sc hre i t e t * werden die B-Rege Ln zu ihrer 




360 



vollständigen Bewertung untersucht. In Abhängigkeit vorn Ergebnis 
kommt die Diagnose in das "Working-Memory" (das alle 
aktiven Pat hokonzept e enthält). FUr die Diagnosen im Working-Me- 
mory sind aLle ihre Regeln aktivierte für die übrigen nur die F 
und F&B-Regeln. 

In extrem großen Anwendungsbereichen kann die Unterscheidung in 
F-* F&B- und B-Rege ln immer noch zu ineffizient sein. Eine 
weitere Effizienzsteigerung ist durch kontextgesteuerte Aktivie- 
rung von F und F&B-RegeLn möglich. Ein "Kontext" in MED2 ist eine 
ganz allgemeine Di agnose ka t egor i e (z.B. Infektion/* die etabliert 
sein muß* bevor kont ext sensi t i ve Regeln ausgewertet werden* die 
speziellere Diagnosen aktivieren. 



3.4 



Verdach t s überprüf ung 



Die Bewertung von Diagnosen wird in MED2 durch Regeln ausgeführt* 
wobei die Stärke der Symptom-Di agnose -Assoz i at i on mit einer 
Evidenzkategorie bewertet wird. Die "absoluten" Kategorien p7 und 
n7 etabLieren ein Pathokonzept bz w. schließen es aus* während die 
übrigen "probabilistischen" Kategorien pl - p6 und nl - n6 die 
Evidenz für ein Pathokonzept erhöhen bzw. erniedrigen. Darüber 
hinaus gibt es die Kategorie pp* die eine notwendige aber nicht 
hinreichende Vorausse t zung zur Etablierung einer Diagnose 
kennzeichnet. Die probabilistischen Evidenzkategorien aus 
verschiedenen Regeln für dieselbe Diagnose werden so verrechnet* 
daß die Summe von zwei Kategorien der gleichen Stufe gerade dem 
Wert der nächsthöheren Kategorie entspricht (z.B. p3 + p3 = p4) . 
Der Schwel Iwert zur Etablierung liegt knapp Uber der Kategorie 
p5. In dem BeispieLdialog ist bei den probabilistischen 
Bewert ungskat egor i en in Klammern die intern benutze Punktbewer- 
tung mitangegeben (z.B. p4 = 20 Punkte). 

Probabi L i st i sehe Evidenzkategorien sind eine relativ undifferen- 
zierte Ausdrucks weise für die Unsicherheit* mit der Symptom-Di ag- 
nose -Assoz i at i onen bewertet werden. Eine st rukt ur i er t ere Form 
bietet MED2 durch die Möglichkeit zur expliziten Angabe von 
Ausnahmen der Regel* d.h. von Bedingungen* unter denen die 
Assoziation ungültig ist. Regeln mit Ausnahmen erlauben 
insbesondere auch die Verarbeitung von unvollständigen Daten. 
Eine solche Regel kann feuern* auch wenn über die Ausnahmen noch 
nichts bekannt ist (weder ob sie zutreffen noch ob sie nicht 
zutreffen). Wenn spater de t ai l Li ert ere Daten vorLiegen und daraus 
hervorgeht* daß tatsächlich eine Ausnahme einer RegeL vorLiegt* 
wird die RegeL einschließlich aLLer Folgeeffekte wieder 
rückgängig gemacht ( n i c h t -mono t on e s Argument i eren ) . 

Ein Beispiel für die Nützlichkeit von Regeln mit Ausnahmen ist 
ihre Anwendung bei der Bewertung von Symptomen* flir die es 
un t er sch i ed L i che Erhebungsverf ahren gibt: angenommen* ein Symptom 
kann mit einer einfachen* groben und mit e i n e r aufwendigen* 
präzisen Methode festgesteLLt werden. SoLange nur die einfache 
Methode angewandt wurde* wird man Verdacht sdi agnosen aufgrund 
ihrer groben Ergebnisse bewerten* aber sobald die aufwendige 
Methode durchge führ t ist* sollen deren präzise Ergebnisse die 
alten ersetzen. Dies erreicht man in M E D 2 * indem man bei den 
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RegeLn/ die Schlußfolgerungen aus den groben Ergebnissen der 
einfachen Methode ziehen/ das Faktum der Durchführung der 
aufwendigen Methode als "Ausnahme" deklariert. Das bewirkt/- daß 
bei ihrer Durchführung alle alten Regeln zurückgezogen werden und 
die Auswertung der präzisen Ergebnisse an deren SteLLe tritt. 

Die unterschiedlichen Komponenten bei der probabilistischen 
Bewertung einer Diagnose in MED2 erklärt Fig. 2- 



Er wartete 
Sy mpt oma t i k 
einer 
Diagnose 



E&B (Pro): Erwartete und beobachtete Symptome 

E&NB (Kontra): Erwartete aber nicht beobachtete Symptome 

N E&B ( Er k Lärungswert ) : Nicht erwartete aber beobachtete Symptome 




Fig. 2: Komponenten bei der probabi L i st i sehen Bewertung einer 

Di agnose 



Da nur in idealen Fällen die tatsächlich beobachtete und die von 
einer Diagnose erwartete Symptomatik vollständig übereinstimmen/ 
muß der Grad der Ube r e i ns t i mmung abgeschätzt werden. Dazu dienen 
in MED2 die drei Aspekte "Pro”/ "Kontra" und "Erk lärungswert " 
(s. Fig. 2) Der Er k Lärungswert ist eine Art P Lausi bi L i t ät s- 
kontroLLe der Enddiagnosen (s. Kap 3.7) drückt aus/ wie 
vollständig die etabLierten Diagnosen die beobachtete Symptomatik 
erkLären können. 

Das Wissen über die Häufigkeit von Diagnosen wird mit der 
"Prädisposition" erfaßt. Dabei wird von der Apri or i -Häuf i gkei t 
der Diagnose ausgegangen/ die als Konstante oder in Abhängigkeit 
von Grunddaten (z.B. Alter) angegeben ist. Spezielle "Risiko- 
faktoren" (z.B. Lebensgewohnheiten beim Mensch; Fährst iL beim 
Auto) können die Apri ori -Häuf igkei t modifizieren und ergeben die 
Pr äd i spos i t i on . 

Die Bewert ungskomponent en Pro/ Kontra/ Prädisposition und Erk Lä- 
rungswert werden zu einer Gesamt bewert ung der Diagnose zusam- 
mengefaßt/ die mit der ihrer Di f f erent i a Ldi agnosen und mit 
einem abso Luten SchweLlwert verglichen wird. Eine ausführliche 
Beschreibung der hybriden Diagnosebewertung findet sich in [Puppe 
8 6b 3 . 



3.5 



Di fferentialdiagnostik 



Ein typisches ProbLem der Diagnostik ist die Unt erschei dung 
zwischen "Di f f er ent i a Ldi agnosen "/ d.h. zwischen Diagnosen/ die 
Leicht verwechselbar sind/ da sie ähnliche Symptome verursachen. 
Solche Entscheidungen erfordern einen systematischen Vergleich 
zwischen den Konkurrenten/ wobei eine Diagnose nur dann 
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etabliert werden kann* wenn sie erhebLich besser als ihre 
Alternativen beurteilt wird. Für die di f f erent i a LcM agnos t i sehe 
Entscheidungsfindung ist es gleichwertig* ob für die beste 
Diagnose positive Evidenz oder fUr die Konkurrenten negative 
Evidenz gefunden wird* da es nur auf die Differenz an kommt. 

In MED2 kann der Experte beim Aufbau der Ui ssensbas i s fUr jede 
Diagnose eine Menge von Di f f eren t i a Ldi agnosen angeben. Vor ihrer 
Etablierung wird eine Diagnose systematisch mit ihren 
Differentialdiagnosen verglichen. FaLLs keine eindeutige Ent- 
scheidung möglich ist* werden weitere Symptome gesucht* die zur 
Unterscheidung der Alternativen besonders nützlich sind. Wenn 
eine Diagnose etabliert worden ist* werden ihre Di f f erent i a l - 
diagnosen ausgeschlossen. 

Obwohl die Di f f erent i a ldi agnost i k im allgemeinen eine sehr gute 
Technik der Entscheidungsfindung ist* kann sie zu Fehlern führen* 
wenn 

a) keine der Differentialdiagnosen* sondern eine ganz andere 
Diagnose zutrifft (d.h. die Menge der Di f f e r ent i a ldi agnosen 
nicht vollständig ist) oder 

b) mehrere Diagnosen gleichzeitig zutreffen. 

In MED2 gibt es foLgende Mechanismen gegen diese Fehlerquellen: 

- Bei der Etablierung einer Differentialdiagnose muß die Diagnose 
nicht nur erhebLich besser aLs ihre Konkurrenten bewertet 
werden* sondern auch ihre absoLute Bewertung muß ein Minimum 
übersteigen. Dadurch wird erreicht* daß bei einer unvollstän- 
digen Menge von Di f f erent i a Ldi agnosen statt einer falschen gar 
keine gesteLlt wird. 

- Diagnosen* die der Experte nicht als Di f f erent i a Ldi agnosen de- 
finiert* können aLs Me hr f ac hdi agnosen unabhängig voneinander 
etabLiert werden. 

FaLLs eine Diagnose keine Di f f erent i a Ldi agnosen hat* wird sie 
ausschließlich aufgrund ihrer absoluten Bewertung etabLiert. 



3.6 



Diagnostischer Mittelbau 



Der diagnostische MitteLbau ist die Gesamtheit aller Teilinter- 
pretationen der Symptomatik* die den diagnostischen Lösungs- 
prozeß strukturieren heLfen. Seine VorteiLe umfassen: 

- Einschränkung des Suchraumes* da der Ausschluß von Grob- 
diagnosen die Überprüfung ihrer Feindiagnosen erspart. 

- Reduktion der Unsicherheit* da die partie L Le Int erpre t at i on 
der Symptome zu Zwi schenergebni ssen sich auch oft dann 
absichern Läßt* wenn die Enddiagnose noch unbekannt ist. 

- DarsteLLung von partie L Lern Wissen. 

Der diagnostische MitteLbau ist in MED2 aufgeteiLt in: 

- Einfache Symptorni nt erpre tat i onen * die sofort bei der Daten- 
erfassung durchgeführt werden Cs. Kap. 3.2). 

- Komplexere Interpretationen (Grobdiagnosen)* die schrittweise 
zu Enddiagnosen verfeinert werden. 




363 



Die einfachste Verfeinerungsstrategie besteht darin/- in einer 
strengen Hierarchie von Pathokonzept en zunächst auf der obersten 
Hierarchieebene die zutreffende Grobdiagnose zu etabLieren> dann 
einen NachfoLger zu seLektieren/ u s w . (bekannt als EstabLish-Re- 
fi ne- Strategie). Diese Vorgehen sw eise ist aber zu starr/ 
wenn es mehr als einen AbLe i t ungspf ad für eine Feindiagnose gibt. 
Beispie L: in der Medizin können Diagnosen u.a. nach Anatomie 
(Leber/ Nieren/ etc.) oder nach den ZeitverLauf der Krankheit 
(akut/ chronisch/ etc.) einge teilt werden. In einer strengen 
Hierarchie rnuf3 ein Kriterium zum Haup t kr i t e r i um gemacht werden/ 
das durch das andere differenziert wird. Wenn jedoch z.B. die 
Anatomie das Haup t kr i t eri um ist/ ist es nicht mehr mögLich/ eine 
"akute Krankheit” zu represent i er en / da nur noch "akute 
Le.be r e r kr ankung ” und "akute Ni erenerkrankung" darsteLLbar sind 
CSzoLovits 85/ s. Kap. 2-3.13- Deswegen koexistieren in vieLen 
Anwendungsbe re i c hen verschiedene hierarchische Einteilungen (z.B. 
in der Medizin symptomatische/ ät i o Logi sehe / anatomische/ 
chronologische und pat hophysi o Logi sehe Hi erarchi en) / und es wird 
für jeden Einzelfall entschieden/ welches die geeignetste ist. 

Zur Realisierung auch von mehrfachen oder sich lieber Lappenden 
Di agnoseh i erar c h i en dienen Di agnose -Di agnose RegeLn/ die in 
Abhängigkeit des Status einer Diagnose (etabliert oder 
ausgeschlossen) und eventueLLen weiteren Bedingungen Evidenz auf 
andere Diagnosen übertragen. In den meisten FäLLen sind die 
NachfoLger einer Diagnose unt e r e i nande r Di f f erent i a Ldi agnosen/ da 
sie um die Erklärung der übergeordne t en Diagnose konkurr i er en . 
Durch RegeLn zur Ve r dac h t sgen e r i e r ung kann die Hierarchie auch 
übersprungen und direkt eine Feindiagnose aktiviert werden. Da 
die diagnostische Vorgeh enswe i se in muLtipLen Hierarchien 
manchmal auch von "unten" nach "oben" ver Läuft/ können zirkuläre 
Ab L e i t ungske t t en entstehen/ die insbesondere bei der Zurücknahme 
von Schlußfolgerungen zu Verfälschungen führen würden. Zur 
Vermeidung soLcher Verzerrungen werden zirkuläre Ab Le i t ungske 1 1 en 
in MED2 blockiert (s. Kap. 4.3). 



3-7 



Stellen der Enddiacinose 



Das SteLLen der Enddiagnose umfaßt zunächst die Ausgabe der 
etabLierten Pat hokonzept e nach AbschLuß der Sympt omer f assung . 
Wenn die etabLierten Pat hokonz ept e jedoch nicht alLe vorhandenen 
Symptome erklären können/ soLLten auch die nicht etabLierten 
Pa t hokonz ept e mit hoher Evidenz berücksichtigt werden. Dazu 
werden Symptome zu Gruppen ähnlicher Bedeutung zusammengefaßt und 
nach ihrem Schweregrad gewichtet (aLs " Exp L ana t i onse t s " ) . Wenn 
nach AbschLuß der Symptomerfassung und Bewertung noch unerklärte 
Exp Lanat i onse t s übr i ggeb L i eben sind/ die durch ein Pathokonzept 
i rn Working-Memory erkLärt werden können/ so wird ihre Bewertung 
durch einen entsprechenden Bonus verbessert/ was ihre Et ab Li er ung 
bewirken kann. Die Berücksichtigung des Er k lärungswer t es der 
Diagnosen hat damit die Funktion einer Plausi bi Li t ät skontro L Le 
der Endergebnisse (sind alLe wichtigen Symptome durch die 
Enddiagnosen abgedeckt/ d.h. erklärt?). 
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3.8 



Therapi ese Le kt i on 



Nach EtabLierung einer Diagnose berechnet ME D2 mit entsprechenden 
RegeLn die vorliegende Variante der Diagnose* die direkt mit 
einem Th er api e vor sc h L ag gekoppelt ist. Falls keine spezielle 
Diagnosevariante herge leitet werden kann, wähLt MED2 die 
"De f au L t "-Var i ant e aus. Der Ther api evorsch lag besteht im 
einfachsten Fa l L im Ausdrucken von Text; es ist aber auch 
möglich* MED2 über eine vorgesehene Programmschni t tste l Le mit 
de t ai l L i ert en Th e r ap i eprogr ammen zu koppeln. 

Im NormaLfaLL gibt MED2 den Therapi evorsch Lag erst am Ende einer 
Sitzung aus und berücksichtigt dabei die Di agnoseh i erarch i e * 
indem Therapi evorsch Läge jeweiLs nur flir die Enddiagnosen gemacht 
werden. Wenn die Ther api ernaßnahme besonders dringlich ist* kann 
MED2 aber auch sofort nach EtabLierung einer Diagnose die 
Therapi e.anwe i sung dein Benutzer mitteiLen. 



3.9 



Therapi e auswert unci 



Wenn die Therapie nicht zum gewünscht en Erfolg führt* so Liefert 
sie meist wertvolle Hinweise* die bei der eventuell notwendigen 
Revision der ur sprüng L i ch en Diagnose nütz Lieh sind. Dazu gehören 
sowohl der direkte RückschLuß vom Therapi eerfo Lg auf die 
Diagnose* aLs auch die Auswertung zeitlicher Veränderungen von 
Symptomen unter therapeutischem EinfLuß. 

Beides wird in M E D 2 berücksichtigt. Der Benutzer führt 
mit MED2 eine FoLgesitzung durch* indem er zunächst die Dauer 
seit der Letzten Sitzung eingibt (zum Aktualisieren früherer 
Zeitangaben)* dann in spezieLLen Therapi e -Quest i onse t s die durch- 
geführten Therapi emaßnahmen sowie deren ErfoLg angibt und 
schließlich spezifiziert* wie die Symptomatik sich im einzelnen 
verändert hat. Aufgrund der neuen Informationen revidiert MED2 
dann die aLten Ergebnisse (s. Kap. 4.4). 



4 



SpezieLLe 



Mec hani smen 



In diesem KapiteL werden spezieLLe Eigenschaften von MED2 
ausf ühr L i eher dargestellt* die die Beschreibung der Inferenz- 
strategie in Kap. 3 ergänzen. 



4.1 



Di a logst euerung 



Je nach Art der Symptomeingabe kann man foLgende prinzipielle 
DiaLogmodi von Di agnost i k-Expert ensyst emen unterscheiden (die 
in der Praxis meist kombiniert werden müssen): 
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a) eingebettete Systeme* die ihre Daten direkt von Meßgeräten 
bekommen . 

b) interaktive Systeme* die mit dem Benutzer einen Dialog führen. 
Si e unt erg L i edern sich in: 

bl) passive Systeme* die vom Benutzer vorgegebene Daten 
verarbeiten und 

b2) aktive Systeme* die i ni Dialog die Initiative haben und 
vom Benutzer Daten erfragen. 

Eingebettete Expertensysteme erfordern meist eine Vorver arbe i t ung 
der Daten zum Erkennen von Meßwert f eh lern und zur Datenabstrak- 
tion. Die Vorverarbe i t ung ist reLativ einfach* wenn die Meßgeräte 
numerische Daten liefern und kann beliebig aufwendig werden* wenn 
komplexere Muster (z.B. EKG oder Bi Lder) i nt erpret i ert werden 
müssen. 

In interaktiven Systemen übernimmt meist der Benutzer die 
Vorverarbeitung der Daten. In passiven Systemen besteht das 
Hauptproblem darin* in welcher Form der Benutzer dem System 
seine Symptome m i 1 1 e i L e n kann. In aktiven Systemen wird der 
Di a Log vom Programm gesteuert. Dabei können foLgende ProbLeme 
auftreten: 

- Eine verwirrende Reihenfolge bei der Sy m torn erfass ung. 

- Ein unnötig Langer DiaLog durch Erfragen unwichtiger Symptome. 

- Die vermeidbare Indikation aufwendiger und risikoreicher tech- 
nischer Untersuchungen. 

In MED2 können a Lie Di a Log modi kombiniert werden. Die kLeinste 
Einheit der Symptomerfassung sind dabei nicht einzelne Fragen 
(Manifestationen)* sondern Questionsets. 

Wenn Daten von Meßgeräten verarbeitet werden so Lien* muß MED2 
nur um ein Sc hn i 1 1 s t e L L enprogr a nun zu dem Meßgerät erweitert 
werden. Je nach Komplexität kann die notwendige Vorver arbe i t ung 
der Daten innerhalb von MED 2 mit Rege Ln und abgeleiteten 
Manifestationen in einem Questionset oder außerhalb von MED2 
durch ein anderes Programm durchgeführt werden. Dabei können auch 
Meßge rät de f e k t e a Ls Diagnosen herge Leitet werden und bei der 
Interpretation der Daten berücksichtigt werden (s. Kap. 4-6). 

FaLLs der Benutzer aktiv Symptome eingeben wiLL* wähLt er 
in hierarchisch strukturierten Menüs die Quest i onsets aus* 
die seine Beobachtungen umfassen. Gibt der Benutzer keine 
Questionsets vor* übernimmt MED2 die Initiative: 

1. Zunächst wird überprüft* ob Questionsets aufgrund kategori- 
scher RegeLn indiziert sind. Das entspricht einer standardi- 
sierten* erfahrungsgesteurten Sympt ornerh ebung . 

2. FaLLs diese Strategie zu keinem Ergebnis führt* wird der Ques- 
tionset ausgewähLt* der zur Überprüfung der Diagnosen im 
Work i ng -Memory am nützlichsten ist. 

3. Bei sehr allgemeiner Symptomatik kann es passieren* daß über- 
haupt keine brauchbaren Ve rdac h t shy po t h e s en herLeitbar sind. 
Zur Klärung solcher Situationen gibt es in MED2 ganz 
allgemeine Kontext-Diagnosen* die dann die Dialogsteuerung 
übernehmen. Ihre Questionsets beinhalten eine eher systema- 
tische Erfassung der Symptomatik* die in dem et ab Li er ten 
Kontext relevant ist. 
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Ein SpezialfaLL ist die Etablierung einer Diagnose* an die sich 
häufig Fragen und Ableitungen zur Klärung ihres Typs und 
Schweregrades anschließen. Sie können in MED 2 in einem 
diagnosespezifischen Questionset zusammengefaßt werden* der 
direkt nach der Etablierung der Diagnose aktiviert wird. 

Der Hauptvorteil des Quest i onset -Konzept es zur Dialogsteuerung 
ist die Bündelung zusammengehöriger Fragen zu einer Steuerungs- 
einheit. Der daraus resu Lt i erende* mögliche Nachtei L einer zu 
detaillierten Erfassung der Symptome kann durch eine hierarchi- 
sche Organisation der Fragen innerhalb eines Questionsets 
ausgeglichen werden. 



4.2 



Not f a l Idi agnost i k 



Notfalldiagnostik unterscheidet sich von "normaler" Diagnostik 
dadurch* daß bei Erkennen von kritischen Situationen sofort 
Aktionen eingeLeitet werden müssen* ehe die Diagnostik 
abgeschlossen ist. Das bedingt: 

- Eine Dialogsteuerung* die sich nur auf die wichtigsten 
( h and Lungsre l e vänt en ) Symptome konzent r i er t . 

- Die vordring li che Untersuchung von den Diagnosen* die soforti- 
ges Handeln erfordern. 

- Die sofortige Ausgabe von Hand lungsanwe i sungen nach Etablierung 
einer Not f a L Ldi agnose . 

In MED2 kann eine kritische Situation als ein Pathokonzept 
definiert werden* das durch eine besondere Priorität ausgezeich- 
net ist und deswegen auch bei reLativ geringem Verdacht vorrangig 
untersucht wird. Falls es et ab Li er t wurde* druckt MED 2 die 
ent spree henden Therapi emaßnahmen sofort aus* faLLs diese durch 
eine hohe Dringlichkeit gekennzeichnet sind. 

Das Hauptproblem bei efer Not f a L Ld i agnos t i k ist rasche und 
fokussierte Symptomerfassung. Sie hängt von der QuaLität der 
Benut zerschni t tste L Le und der Anzahl der eingegebenen Symptome 
ab. In MED2 entspricht Letzere der AnzahL der Fragen in einem 
Questionset* die gesteLLt werden. Die Festlegung der optimalen 
Größe eines Questionsets ist insofern relativ schwierig* da seine 
Struktur beim Aufbau der Wissensbasis festgelegt werden muß und 
während einer Sitzung nicht geändert werden kann. 

Wenn die im NotfaLL e r f orde r L i c h e Sy mp t ome r f a s sungs s t r a t eg i e 
keine zu große VariabiLität auf weist* ist die beste Strategie in 
MED2* spezielle "No t f a L L -Quest i onse t s " aufzubauen* die nur die 
jeweils wichtigsten Symptome erfassen und bei Erkennen des 
NotfaLLs aktiviert werden. 
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4.3 



Ni cht -monotones Argument i eren 



Ni cht -monotones Argumentieren ist die Fähigkeit* ungtlltig 

gewordene Schlußfolgerungen zu erkennen und zurückzuziehen. 
In MED 2 ergibt sich der Bedarf zum Zurückziehen von 

Schlußfolgerungen ( Be l i e f -Revi si on ) in folgenden Situationen: 

- Der Benutzer korrigiert eine frühere Eingabe. 

- Eine Ausnahme einer gefeuerten Rege L wird bekannt. 

- Die Bewertung einer bereits etablierten Diagnose versch Lecht ert 
sich durch neue Symptome erhebLich. 

- Symptome ändern sich in Fo Lge s i t Zungen . 

Da die Rücknahme von Sch Lußf o Lgerungen sehr zeitaufwendig sein 
kann* benutzen wir in MED2 einen die Besonderheiten der 

Diagnostik ausnutzenden Be L i e f -Re vi si on-A Igor i t hrnus [Puppe 87]. 
Die Hauptidee ist die BLockade zirkulärer Begründungen . 

Zirkuläre Ableitungsschleifen sind in der Diagnostik sinnvoll und 
notwendig* um eine Korrelation zwischen Pat hokonzept en auszu- 
drücken* ohne dabei die Vorgehensweise bei der EtabLierung 

f est zu Legen . 

Ein BeispieL aus dem Bereich der Le ber er krankungen : Die 

Pat hokonz ept e "Pf ort aderhochdruc k" und "Leberz i r rhose " korreLie- 
ren stark miteinander* d.h. wenn das eine Pathokonzept etabLiert 
ist* wird auch das andere sehr wahrscheinlich. In MED 2 
r epr äsen t i er t man diese Korrelation durch zwei Regeln: 

Pfortaderhochdruck ==> Leberzirrhose (mit Evidenz x) 

Leberz i rrhose ==> Pf ortaderhochdruck (mit Evidenz y) 



Die Problematik dieser Situation für den Be L i e f -Re v i s i on -A Lgo- 
rithmus zeigt Fig. 3. 
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Fig. 3: eine Ab Leitungsschleife 



In MED 2 wird das Sc h L e i f enprob L e m für den Be L i e f -Revi si on -Prozeß 
durch einen Mechanismus sehr effizient geLöst* der schon das 
Entstehen von Zirkelschlüssen verhindert* die deswegen im 
Be Li e f -Revi si on-ALgori t hrnus nicht berücksichtigt werden brauchen: 
alle an einer Schleife beteiligten RegeL.n (d.h. soLche* die 
Evidenz für ein Pathokonzept Liefern* weil das Pathokonzept 
etabLiert worden ist; in Fig. 3 die Rege Ln PI -> P2 und P2 => 
PI) werden beim Aufbau der Wissensbasis als "zirkulär" 
gekennzeichnet. SobaLd das Pathokonzept* das sie herleiten* 
während einer Sitzung etabLiert ist* werden sie bLockiert. 
Dadurch wird erreicht* daß niernaLs aLLe RegeLn in einer SchLeife 
feuern können. BeispieL: wenn in Fig. 3 die RegeLn SI => PI und 
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PI => P2 gefeuert haben* dann ist die Regel P2 => PI blockiert* 
weil PI schon etabLiert ist. Entsprechend wäre die Regel PI => P2 
bLockiert* wenn P2 vor PI etabliert worden wäre. Das Blockieren 
zirkularer Regeln führt zu keiner Verfälschung des Inferenzpro- 
zesses* da nur solche Regeln bLockiert werden* die für ein 
bereits etabLiertes Pathokonzept zusätzliche Evidenz Liefern 
würden . 



4.4 Repräsentation der Zeit 



Das Wissen um die zeitlichen ReLationen von Symptomen verbessert 
die Genauigkeit der Diagnostik erheblich. Am einfachsten lassen 
sich zeitliche ReLationen (wie die meisten übrigen Symptome) 
durch Schlagwörter (z.B. Dauer von Symptom X = "3 - 6 Stunden”* 
"Symptom A vor B aufgetreten” ) repräsentieren*- wobei der Benutzer 
die SchLagwörter aus einem Menü auswähLt* die die vorhandene 
Symptomatik arn besten beschreiben. Diese Dars t e L Lungs f orrn 
erfordert redundante Fragen* wenn viele zeitliche ReLationen 
beschrieben und verglichen werden müssen* da jede Relation mit 
einem eigenen SchLagwort belegt werden muß. Außerdem verfügt sie 
über keine Möglichkeit* den Begriff des "jetzt” in Fo Lge si t zuncien 
automatisch anzupassen. Beispiel: wenn in der Er st Sitzung die 

Beschwerden seit drei Wochen bestehen und in einer neuen Sitzung* 
die drei Tage spä"ter stattfindet* nicht verschwunden sind* dann 
soLLte das System herLeiten können* daß die Beschwerden jetzt 24 
Tage Lang anh 2 Lten* was mit Sc h L agwör t e rn nur sehr mühsam dar- 
stellbar ist. Zur Errnög L i chung so Lehe r Ableitungen und zur 
Vermeidung von Redundanzen in den Fragen verfugt KED2 über eine 
explizite Zeitrepräsentation* mit der es Zeitrelationen aus den 
Zeitangaben des Benutzers herLeiten kann (u.a. auch obiges 
Beispiel). 

MED2 hat die zei tbezogenen Fragetypen "Zeitpunkt"* "Dauer" und 
"Frequenz". Aus diesen Rohdaten kann M E D 2 folgende Schlußfolge- 
rungen herLeiten: 

- Dauer eines Symptoms aus Beginn und Ende. 

- Zeitliche Beziehung (mit den Prädikaten $vor* $g leichzeitig und 
Snach) zwischen zwei Symptomen* wobei die Beziehung durch ein 
Zeitintervall präzisiert werden kann. 

- In Fo Lgesi t zungen : Umrechnung aller Zeitangaben* die sich auf 

den alten Unt ersuchungsze i tpunk t beziehen 

- In Fo Lgesi t zungen : Erkennen einer zeitlichen Änderung eines 

Symptomes (mit den Prädikaten SZunahme* SAbnahme und SKonstanz) 
unter dem Einfluß besonderer Ereignisse* z.B. (SAbnahme Öldruck 
10 (5 Stunden) (nach ö Lwechse Ize i tpunk t ) ) * d.h. der ÖLdruck hat 
um mindestens 10 Einheiten innerhalb von 5 Stunden abgenommen* 
wobei in dieser Zeit ein ÖLwechseL st at t ge f unden haben muß. 
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4.5 



Repräsentation der Anatomie 



Der Wertebereich von Lokalisationsfragen kann in MED 2 durch 
Referenz auf ELemente einer allgemeinen Lokalisationshierarchie 
angegeben werden. Dieser Mechanismus der indirekten Referenz hat 
folgende Vorteile im Vergleich zur direkten Auflistung der 
möglichen Lokalisationen im Wertebereich einer Frage: 

- Ökonomie beim Aufbau der Wi ssensbasi s * da die Loka L i sat i ons- 
hierarchie einmaL aufgebaut wird und in speziellen Fragen nur 
ein Referenzobjekt in der Hierarchie aLs Werte bereich angegeben 
werden muß. 

- Mög lichkeit der Repräsentation von allgemeinem Wissen über 
Lokalisationen (derzeitig h i erarch i sehe Beziehungen und 
rechts/Links Symmetrie)* das flir den Rege 1 i nt erpre t i erer 
wichtig ist. 

- Möglichkeit einer graphischen Loka l i sat i onse i ngabe * indem die 
Lokalisationshierarchie auf dem Bildschirm visualisiert wird 
und der Benutzer den entsprechenden Bereich auf dem Bildschirm 
mit der "Maus" ank Lickt* anstatt den Namen der Loka Li sat i on 
eintippen zu müssen. 

Der RegeLinterpretierer nutzt das Wissen über LokaLisationen aus* 
indem er bei dem Test auf GLeichheit von LokaLisationen erkennt* 
daß eine LokaLisation eine andere umfaßt (d.h. in der 
Hierarchie weiter oben steht) und indem er Kons i s c enzprüf unejen 
bezüglich der Seitigkeit von LokaLisationen durchführt* z.B. 
($g Leichseitig Loci Loc2 Loc3)* d.h. die LokaLisationen Loci* 
Loc2 und Loc3 müssen auf derselben Seite Liegen. 
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Plausibilitätskontrolle der Eingabedate n 



Eine Diagnose kann nicht besser sein als die QuaLität der 
Eingabedaten. Zu ihrer Überprüfung gibt es in MED2 foLgende 
Mechani smen : 

- Einschränkung des Wer t ebere i chs bei Fragen (z.B. ALter des 
Menschen 0 - 120 Jahre) 

- Kennzeichnung von inkonsistenten Kombinationen versch i edener 
Fragen durch spezielle Regeln (wenn eine solche RegeL feuert* 
wird der Benutzer aufgefordert* eines der Fakten* die zu der 
Inkonsistenz geführt haben* zurlickzuzi ehen) 

- Herleitung der Ung Laubwürdi gkei t einer Datenquelle und Blockie- 
rung der diese Daten auswertenden RegeLn. Die Unglaub- 
würdigkeit wird aLs Diagnose etabliert und aLs Ausnahme zu 
den betroffenen Dat envorverarbe i t ungs-Rege Ln angegeben. Dadurch 
wird der In f e r enzprozeß nur dann beeinflußt* wenn tatsächlich 
ein AnLaß dazu besteht. 

Allerdings wird für eine umfassende Überprüfung der Zuverlässig- 
keit der Eingabedaten meist ALLgemein wissen gebraucht* das in 
spezialisierten Systemen nicht vorhanden ist. Daher bleibt die 
PLausi bi Li tat skont ro L Le der Eingabedaten ein kritisches ProbLem 
beim Einsatz von Di agnost i kexpert ensys t enien . 
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j Wj B S | sensr^g [ räs^n^tj^^ 



Zur Entwicklung einer Wissensbasis muß der Experte "nur" die 
Objekttypen von MED2 i nst anz i i eren : 

- Manifestationen (erfragte und abgeleitete Symptome) 

- Questionsets (Gruppen zusammen erfragter Symptome) 

- Exp Lanat i onset s (Gruppen von Symptomen ähnlicher Bedeutung) 

- Pat hokonzept e (Grob- und Feindiagnosen) 

- Varianten ( Therapi evari ant en der Endd i agnosen ) 

- Loka Li sat i onen ( Loka Li stat ionsheterarchi e fUr die Symptome) 

- Regeln (Angabe der Beziehungen zwischen den Objekten) 

Dazu benennt der Experte die Objekte und spezifiziert ihre 
At tri but er z.B. fUr Manifestationen: 

- Zugehörigkeit zu Questionsets 

- Ableitungstyp (erfragt oder abgeleitet) 

- Auswertungsschema flir abgeleitete Manifestationen 

- Frage text für erfragte Manifestationen 

- Fragetyp (one-choice* mu Lt i p le -choi c e * numerisch/ Zeitdauer* 
Zei t f requenz * Zeitpunkt* Loka L i sat i onsangabe ) 

- Wertebereich (Spezifizierung der sinnvoLLen Antwort a Lternat i ven ) 

- Erk L är ungs text e zu Fr age text und Antwort a Lternat i ven 

- Zeitlicher Fragetyp (Frage so L l nur in erster Sitzung* nur ab 
der zweiten Sitzung oder immer gesteLLt werden können) 

Diagnosen werden charakterisiert durch: 

- Apr i or i -Wahr sch e i n L i c hke i t 

- Nachfolger in der Diagnoseheterarchie 

- Di f f eren t i a Ldi agnosen 

- Exp Lanat i onset s * die durch die Diagnose erkLärbar sind 

- Nützlichkeit von Questionsets zu ihrer Verdacht süberprüfung 

- Questionset zur Bestimmung ihrer Therapi evari an t e 

- mögLiche Varianten 

- Def au L t -Vari ant e 

- Auf rnerksamkei tsf aktor 

Alle kompLexen Beziehungen zwischen Objekten werden durch Rege Ln 
spezifiziert- Eine Regel hat das aLLgemeine Format: 



Aktivierungsbedingung & Bedingung ==> Aktion ||- Ausnahmen 

Die Aktivierungsbedingung gibt den Kontext (allgemeine Pathokon- 
zepte) der RegeL an* der gültig sein muß* bevor die eigentliche 
Bedingung ausgewertet wird. Sie besteht aus einer Konjunktion von 
Prädikaten* die Zustände und ReLationen der Objekte abfragen 
(z-B. $vor* Sg Lei chsei t ig* SZunahme* etc-)- Im AktionsteiL werden 
Diagnosen* Varianten* abgeleitete Manifestationen und ExpLa- 
nationsets bewertet* erfragte Manifestationen und Questionsets 
indiziert bzw. ausgeschlossen oder Widersprüche erkannt. 
Ausnahmen werden aLs eigenständige Recje Ln repräsen t i ert * dessen 
AktionsteiL die Rücknahme anderer Rege Ln ist. Diese DarsteLLung 
hat den VorteiL* daß auch zu Ausnahmen Ausnahmen angegeben werden 
können . 
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Die bisherigen Erfahrungen mit dern Aufbau von Ui ssensbasen in 
MED2 bestätigen die Entscheidung/ ein spezielles Di agnost i kwerk- 
zeug zu entwicke Ln- Ein zentrales Problem bei der Evaluation von 
Expert ensystemwerkzeugen ist jedoch/ daß die Erstellung 
er f o Lgre i eher Demons t rat i onsprot o typen nur wenig aussagekräftig 
ist- Da M E D 2 gerade im Hinblick auf die Feinanpassung einer 
Wissensbasis entworfen worden ist/ ist seine umfassende Bewertung 
derzeitig nicht möglich. Trotzdem läßt sich absehen/ daß zu einem 
integrierten Di agnost i k-She l L gLobaLe Ve rbe sserunejen in folgenden 
Bereichen notwendig sind: 

* Bei der Int ervi ewe r kornponent e : Vor aLlem Integration von BiL- 
dern zur Symptomerfassung. 

* Bei der Ui ssenserwsrbskornponent e : Pr ob Lern bezöge ne statt syntax- 
orientierte Führung des Ui ssenserwebsdi a löge s . 

* Bei der Prob lern lösungskornponent e : Neben läufige Verfolgung von 
schwer zu stellenden Differentialdiagnosen. 

* Bei der Ui ssensr epr äsent a t i on : Darstellung und Auswertung auch 

von Falldatenbanken und kausalem Wissen. 



7. Beispiel 



Das folgende Beispiel aus der von H. P. Borrmann entwickelten 
Wissensbasis Uber K F Z-Mot oren-Di agnost i k (M0DIS2) illustriert vor 
aLlem die Behandlung von Fo Lgesi t Zungen in MED2. Fig. 4 gibt 
einen UberbLick Uber den zeitlichen VerLauf der Haupt Symptome "zu 
hoher Kr af t st of f ver br auch " und "Beanstandungen im KaLtLauf" sowie 
den km- St and. 







/ WocUerv 
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In der ersten Sitzung ermitteLt M0DIS2 vier Diagnosen 
(Zündkerzen* St rombergvergaser * LuftfiLter und ZUndeinste L Lung) 
und macht dazu Therapi evorsch Läge (Bl). 

Daraufhin verschwinden die Symptome/ aber nach sechs Monaten 
kommt der Kunde erneut mit ähnLicher Symptomatik in die 
Werkstatt. In der 2. Sitzung modifiziert der Benutzer die Daten 



von der ersten Sitzung und mach 
Therapiemaßnahmen (B2). Daraus 
Vergaser"/ "St ar t aut omat i k " un 
Aus der Begründung der Zündker 
trotz des Zündkerzenuechse Ls na 
wieder verbraucht sein können* 
nach dem Austausch der Zündk 
Prädisposition in B5) und se 
20000 km gefahren sind (Begr 
Letzten RegeL in B6 "Ausnahme tr 

Nachdem in der dritten Sitzung 
und Vergaserei nst e L Lung die Be 
haben (Kraftstoffverbrauch stat 
aber nicht verschwunden sind* 
weniger w a h r s c h e i n L i c h und n i 
Zlindkerzenwechse L gerade erst 
übrig bleibt nur die Diagnose " 
TherapievorschLag der zweiten Si 



t Angaben Uber die durchge f ührt en 
werden die Diagnosen "Stromberg- 
d "Zündkerzen" hergeLeitet (B3). 
zen ( B4* B5 * B6) geht hervor* daß 
ch der ersten Sitzung diese schon 
da die neuen Be anst andungen erst 
erzen aufgetreten (Begründung der 
it der Letzten Therapie mehr a Ls 
Undung der Ni cht -Ausführung der 
i f f t zu"). 

trotz erneuten ZUndkerzenwechse Ls 
anst andungen sich zwar verbessert 
t 12 L nur noch 11 L pro 100 km)* 
ist sind die Zündkerzen jetzt 
cht mehr etabliert* da der Letzte 
s t a 1 1 ge f linden hat (B7 und B8) . 
Startau to matik" * die entgegen dem 
tzunq nicht überprüft worden war. 



id 



ME02 1. Sitzung Questionset: 


>REPARA7UR< 


ETABLIERTE DIAGNOSEN 


VERDACHT S-D1A6N0SEN 


VERDACHT AUF ZUENDEINSTELLUNG 


STARTAUTOMATIK ( 3B > 


luftfilt!r_typ-v 


KABEL ( 20 ) 


STROMBERGVERGASER 


KRAFTSTOFFANLAGE (10) 


ZUENDKERZEN 


TRIEBWERK (10) 





Vorschlaege zur Behandlung der Enddiagnosen: 

FBI 4000: ZUENDKERZEN < T-ZUENDKERZEN_TYP-A ): 

UEBERPRUEFEN SIE DIE ZUENDKERZEN I 

EUER DIESEN TYP VERWENDBARE ZUENDKERZEN SIND: BOSCH WH7 
ODER BERU X7 

PI 13000: STROMBERGVERGASER ( TP-VERGASER ) : 

UEBERPRUEFEN SIE DIE VERGASEREINSTELLUNG' 

P1 19000: LUFTF ILTER_TYP-V ( T-LUFTFILTER-4_7YL_ >: 

UEBERPRUEFEN SIE 0EN LUFTFILTEREINSATZ' 

LUFTFILTEREINSATZ - ERSATZTEILNR . : LFE-004 
P5 1 00 1 C : VERDACHT_AUF_ZUENDE INSTELLUNG ( T -ZUENDE I NSTELLUNG ) : 

UEBERPRUEFEN SIE DIE ZUENDEINSTELLUNG 



MED2 2. Sitzung Questionset: 


>TP-ZUENDANLAGE< 


Etablierte Diagnosen 


VERDACHTS-DIA6NOSEN 


VERDACHT AUF_ZUENDEINSTELLUN6 


STARTAUTOMATIK (35) 


LUFTFILTER TYP-V 


KABEL ( 20 ) 


STROMBERGVERGASER 


KRAFTSTOFFANLAGE (10) 


ZUENDKERZEN 


TRIEBWERK (10) 


WANN HABEN SIE DIE ZUEN0KERZEN GEWECHSELT? 


Bitte geben Sie eine Zeit oder — fuer unbekannt an (? » Optionen) 


Zeitangabe: 1 d aft session! 
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MED2 0. Sitrung Cues t i onset : 


MP-UERGASERANLAGE-: 


ETABLIERTE DIAGNOSEN 


VERDACHTS-DIAGNOSEN 


STRONEERGVERGASER 


KABEL C0) 


ZUENDKERZEN 


KRAFTSTOFFANLAGE <10) 


STARTAUTOMATIK 


TRIEBWERK (10) 



Uebersicht der Ergebnisse 

STROMBERG'JERGASER 

— > STARTAUTOMATIK 
ZUENDKERZEN 



Vorschlaege :ur Behandlung der Enddiagnosen: 

P 1 I 3700 : STARTAUTOMATIK < T-STARTERANIAGE > : 

UEBERPRUEFEN SIE DIE STARTAUTOMATIK! 

PSUeCO: ZUENDKERZEN ( T-ZUENDKERZEN_TYP-A ) : 

UEBERPRUEFEN SIE DIE ZUENDKERZEN ' 

FUER DIESEN TYP VERWENDBARE ZUENDKERZEN SIND: BOSCH WH7 
ODER BERU X7 



Erl laerungsl omponent e ru MED2 


Bewertung von ZUENOKERZEN : etabliert <48)' 


Notwendige Bedingung 


- 


Hinreichende Bedingung 


- 


Ausschluss 


- 


Pro 


wahrscheinlich (40) 


Kontra 


neutral <0) 


Erl.laerungswert 


- 


Praedl sposi t ion 


haeufig 


Di f ferentialdiagnostik 


- 


Varianten 


T-ZUENOKERZEN_TYP-A 



Erl laerungsl omponentc ru MED? 

Begruendung von ZUENDKERZEN : ESTABLISHED < 48 ) 

Begruendung von pro: uahrscheinl ich (40) 

P4 <Z0) Weil NOF.MIERTER-KRAFTSTOFFUERPRAUCH = ERHEBLICH ZU 
HOCH 

Activation: ZUE.NDANL A&E.6EN2 IN 

14 CO) Weil MOTORSTART - MOTOR SPRINGT KALI SCHLECHT AN 

Act ivat ion: ZUEMüANlAGE_BENZ IN 

Begruendung der Fraedispos i t ion haeufig (15) 

P2 (5) Uegen Apr i er l -wahr sr he i n 1 j chle j t de* Pat hol onrept s 
P2 (5) Ueil ZUENDKER7ENALTER ist um Mindestens ü 1 
groesser als 

EEANSTANOUNGSOAUER_KRAFTSTOFPUERBPAl'CH 
P? <S) Ueil ZUENDKERZENALTER ist um mindestens 0 I 

groesser als EEANSTANDUNG50AVFR_M0T0RSTART 
Begruendung fuer Variante: T- ZUENDKERZEN_T'i F-A 
F6 (80) Ueil MOTORTYP - VU-GOLF_C 

und BAUJAHR inner hü 1b von 1 9S3 und 1985 



Er I 1 eerungsl enponent e zu MEDZ 

Negative ni c ht -ge Teuer t e Regeln von ZUENDKERZEN 
N2 (-5) Wenn ZUENDKERZENALTER ist un mindestens D I 
I 1 e l r.er al s 

EEANSTANDUN6SPAUER_FAHFEIGENSCHHFTEN 
Grund: BE ANS TANDVNG SD AUEP_F ÄHRE I GENSCHAF TEN ist nicht erfasst 

N2 (-5) Wenn Nicht MQTORSTAfiT *= MOTOR SFRINC-T KAlT SCHLECHT 
AN 

Grund: MOTORSTART • MOTOR SPRINGT KALT SCHLECHT AN 

N? (-5) Wenn THEFAF IE ZUENDUNG « ZUENDKERZEN GEWECHSELT 

ausser Wenn KM- ST AND: 

Anstieg: mindestens 00000 

Freigms: nach ZEI T FUNK T_ZUENCiKEFZE f . ‘WECHSEL 
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ME DZ 3. EiTrur.y 
El GELIERTE Dl AGNüsEN 
START AUTOMATIK 



Quest 1 onset : TF- VERGASER ALL AGf. '' 

VERtf-.CHlS-ÜjA&^ÖSHj 

ETROMBEFGVF.FC-ASER (35) 
ZUENDKERZEN ( 30 > 



KABEL ( 20 ■ 

KRAFTSTOFF A'L AGE (10) 
TRIEBWERK <19? 



STAFTAUTOMATIK 



Uebersicht der Ergebnisse 



Vorschleege rur Behandlung der Er.ddiegnosen: 

Bl 1370O: STAFTAUTOMATIK < T-ST ARTERANLAGE ): 

UEBEF.PRL'EFEN SIE OIE STARTAUTOMAT IK ■ 



1 ? 



Erl laerungsl omponente zu MEDZ 

Begruendung von ZUENDKERZEN : unklar < 3ö > 

Begruendung von Pros wahrscheinlich (30) 

F4 < ZP ) Weil MOTORSTART - MOTOR SPRINGT KALT 5CHLECMT AN 
Activat ion: ZUENDANL AGE.BENZ IN 

P3 (10) Weil NÜRMIERTER-KRAFTSTOFFVERBRAUCH * ZU HOCH 
Activation: Z UENDANL AGE_BENZ I N 

Eegruendung der Preedi sposi t ion durchschnittlich <C) 

PZ (5) Wegen Apriori -wehrschei r.l ichl e i t des Pat hol cnzept s 

NZ (-5) Weil THEFAFIE ZUENDUNG - ZUENDKERZEN GEWECHSELT 

ausser Wenn KM- ST Af JO : 

Anstieg: mindestens 20000 

Ereignis: nach ZE ITPUNKT_ZUENDKERZENWECHSEL 
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EINE " BLACKBOARD "-ARCHITEKTUR ZUR WISSENSBASIERTEN 
REALISIERUNG SOFTWARE-ERGONOMISCHER ANFORDERUNGEN 



Helmut Balzert, Nürnberg 



Zusammenfassung: Die Notwendigkeit, Software nach 
ergonomischen Kriterien zu gestalten, wird heute allgemein ein- 
gesehen. Zur ökonomischen Realisierung ergonomischer Anforde- 
rungen sind geeignete Software-Architekturen erforderlich, die 
nur durch den Einsatz wissensbasierter Systeme zu verwirklichen 
sind. Nach der Beschreibung entsprechender Anforderungen werden 
Aufbau, Art und Inhalt benötigter Wissensbasen skizziert. Das 
Kommunikationsverhalten zwischen den Wissensbasen erfordert 
eine dynamische Architektur, die am besten durch das bei Exper- 
tensystemen verwendete "blackboard" -Konzept realisiert werden 
kann. Zur Realisierung der software-ergonomischen Anforderungen 
werden vier "blackboards" eingesetzt: für die E/A-Sch.icht, die 
Dialog-Schicht, die Anwendungssysteme und das Auskunfts- & Be- 
ratungssystem. Die "blackboards" kommunizieren untereinander 
über Aufträge. Jede "blackboard" ist unterteilt in eine "con- 
trol"- und eine "domain-blackboard". Die Architektur wurde in 
zwei exemplarischen Implementierungen evaluiert. 



1 Anforderungen an Software-Architekturen 

Eine systematische Ableitung der Architektur-Anforde- 
rungen aus Gestaltungszielen der Software-Ergonomie / 2/, /3/ 

ergibt : 

- Die Architektur muß adaptiv bzw. durch den individuellen 
Benutzer an seine Fähigkeiten und Wünsche adaptierbar sein. 

- Es muß Wissen über die Charakteristika des Benutzers (Benut- 
zermodell), seine Intentionen und Konventionen aufbewahrt 
werden. 

- Es muß Fachwissen über die zu erledigende Fachaufgabe, Wissen 
über benötigte bzw. vorhandene Ressourcen (Selbstbild) sowie 
Wissen über aufgabenbezogene Intentionen des Systems vor- 
handen sein. 

- Drei weitgehend unabhängige Aufgabenkomplexe müssen bearbei- 
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tet werden: 

- Abwicklung der gesamten Interaktion mit dem Benutzer 
(Mensch-Computer-Schnittstelle MCS) . 

- Erledigung der jeweiligen Fachaufgabe (Anwendungssysteme 
ASi) . 

- Unterstützung des Benutzers durch Auskunfts-, Beratungs-, 
Hilfe- und tutorielle Leistungen (Auskunfts- und Beratungs- 
system AUS&BES ) . 

Daraus ergibt sich die in Abb. 1 dargestellte Basisarchi- 
tektur. 





Legende: CS = Computersystem 

Abb. 1: Basisarchitektur eines Software-Systems zur Unter- 
stützung software-ergonomischer Anforderungen 

Die Realisierung der einzelnen Aufgabenkomplexe durch 
weitgehend unabhängige Architekturkomponenten ergibt folgende 
Vorteile: 

- Kontextunabhängigkeit der einzelnen Komponenten bis auf defi- 
nierte Schnittstellen. 

- Eine Mensch-Computer-Schnittstelle und ein Auskunfts- & Bera- 
tungssystem kann für alle Anwendungssysteme verwendet werden. 

- Alle Komponenten können getrennt voneinander dem jeweiligen 
Benutzer angepaßt werden. 

- Die Mensch-Computer-Schnittstelle und das Auskunfts- und Be- 
ratungssystem können einen hohen Komfort bieten und alle Mög- 
lichkeiten heutiger Technik unterstützen, da sie nur einmal 
vorhanden sind. 
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- Die Anwendungssysteme können weitgehend von MCS- und AUS&BES- 
Wissen entlastet werden. 

Die Mensch-Computer-Schnit tstelle ist nochmals in eine 
E/A- und eine Dialog-Schicht unterteilt, um Portabilität und Än- 
derbarkeit zu erhöhen. In der E/A-Schicht werden alle geräteab- 
hängigen MCS -Au f gaben , in der Dialog-Schicht alle geräteunabhän- 
gigen MCS-Au f gaben erledigt. 

Zur ökonomischen Erstellung der Anwendungssysteme ist es 
außerdem erforderlich, daß der Anwendungsentwickler sich mög- 
lichst wenig um die Interaktion mit dem Benutzer kümmern muß. 
Eine Analyse heutiger, hochgradig interaktiver Programme hat 
gezeigt, daß zwischen 50?^ und 70 % des gesamten Programmcodes 
für die Mensch-Computer- Interaktion benötigt wird. Daher muß 
für die Schnittstel le zwischen der Dialog-Schicht und den Anwen- 
dungssystemen ein Repräsentationsniveau spezifiziert werden, 
das es erlaubt, die unbedingt notwendigen Informationen auszu- 
tauschen, ohne daß die Anwendungssysteme mit zuvielen Details 
der Mensch-Computer-Schni ttstelle belastet werden. 

Analoge Anforderungen gelten für die anderen Schnittstel- 
len. 



Um zu einer detaillierteren Architektur zu gelangen, ist 
es erforderlich, die benötigten Wissensbasen und ihr Kommunika- 
tionsverhalten zu analysieren. Dies erfolgt im nächsten Ab- 
schnitt. Den dort beschriebenen Anforderungen werden dann im 3. 
Abschnitt die Charakteristika des "blackboard" -Konzepts gegen- 
übe rges te 1 1 t . Im 4. Abschnitt wird ein modifiziertes und erwei- 
tertes "blackboard "-Konzept vorgestellt, dessen Eigenschaften 
im 5. Abschnitt zusammengestellt werden. Abschließend wird im 
6. Abschnitt der Stand der Implementierung beschrieben. 

2 Aufbau, Art und Inhalt der Wissensbasen 

Damit die E/A-Schicht, die Dialog-Schicht, die einzelnen 
Anwendungssysteme sowie das Auskunfts- und Beratungssystem ihre 
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Aufgaben erfüllen können, müssen sie auf Wissensbasen zugrei- 
fen . 



(a) 



Eine solche Wissensbasis (WB) läßt sich generell in drei 
Teile gliedern: 

(a) Wissen über den jeweiligen Bereich 
(z.B. Telefonprogramm), 

(b) Benutzerspezifische Informationen 
(z.B. Telefonliste des entsprechenden 
Benutzers ) 

v 

( c ) Benutzerspezifisches Wissen 

(z. B. Benutzer darf auch priv/iligierte 
aufrufen) . 



(b) 



(c) 



F unkt ionen 



Teil (a) enthält das Strukturelle Wissen und das Fachwis- 
sen des jeweiligen Bereichs. Liegt das Problemlösungswissen 
ebenfalls in (a) - und gilt dies für alle Wissensbasen - dann 
wird nur eine allgemeine Inferenzmaschine benötigt, um die Wis- 
sensbasen zu bearbeiten. Ist das Problemlösungswissen dagegen 
in die Inferenzmaschine inkorporiert, dann gehört zu jeder Wis- 
sensbasis eine eigene Inferenzmaschine. Unabhängig davon, wel- 
che Alternative gewählt wird, ist die Wissensbasis mit der In- 
ferenzmaschine zusammen eine Einheit, die es erlaubt, das vor- 
handene Wissen auszuwerten. Diese Einheit wird im folgenden da- 
her als Wissensquelle (WQ) bezeichnet. Jede Wissensquelle 
stellt in diesem Kontext sozusagen einen Bereichsexperten dar, 
der im Rahmen der Mensch-Computer-Schni ttstelle , des Anwendungs- 
systems oder des Auskunfts- und Beratungssystems Probleme in 
einem definierten Bereich lösen kann. 



Teil (b) enthält die einem Benutzer zugeordneten Informa- 
tionen, z. B. bei einem Telefonprogramm die anwenderspezifische 
T elef onliste . 

Teil (c) enthält Wissen über den jeweiligen Benutzer. 



Beispiel 

Die Wissensbasis "E/A-Konvent ionen" enthält im Teil (a) all- 
gemeine Konventionen als Voreinstellung. Im Teil (c) ist das 
durch Metakommunikation mit dem Benutzer oder durch Beobachtung 
des Benutzers durch die Mensch-Computer-Schnittsteile 
entstandene Benutzerwissen eingetragen. 
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Über Metakommunikation sollen alle Wissensbasen mit 
allen Teilen für den Benutzer einsehbar sein. Generell nicht än- 
derbar für den Benutzer sind die Teile (a) und (b) einer Wis- 
sensbasis. Teil (b) kann jedoch bei Anwendungssystemen durch 
Anwendung der Operationen, die für die jeweilige Wissensbasis 
zur Verfügung stehen, modifiziert werden, jedoch nicht durch 
Metakommunikation. 

Teil (c) wird durch Schreib-/Leserechte nochmals in zwei 
Teile gegliedert. 

Der erste Teil (cl) enthält entweder 

- von der jeweiligen Wissensquelle durch Beobachtung des Benut- 
zerverhaltens ermittelte Modifikationen des Teils (a) oder 

- vom MCS-/AS-Entwi ekler eingetragene Voreinstellungen. 

(cl) kann auch leer sein. 

Der zweite Teil ( c 2 ) enthält vom Benutzer explizit über 
Metakommunikation eingetragene Modifikationen von (a) oder 
(cl). D. h. nur der Teil ( c 2 ) einer Wissensbasis kann über Meta- 
kommunikation vom Benutzer/Anwender schreibend geändert werden. 
( c 2 ) ist bei der Initialisierung der Wissensbasen leer. 

Die Aktivierung einer Wissensquelle erfolgt immer in der 
Reihenfolge ( c 2 ) , (cl), (a), d. h. die Artikulation von Benut- 

zerwünschen hat Vorrang vor den Systemwünschen und diese haben 
Vorrang vor der allgemeinen Standardlösung. 

Für die E/A-Sch.icht, die Dialog-Schicht und die einzel- 
nen Anwendungssysteme sowie das Auskunfts- und Beratungssystem 
lassen sich jeweils sechs verschiedene Wissensquellen identifi- 
zieren, die benötigt werden, um die ergonomischen Anforderungen 
zu erfüllen. 

Es handelt sich um folgende Wissensquellen: 

( 1 ) Wissensquelle, die das Wissen der jeweiligen Schicht ent- 
hält (E/A, Dialog, Anwendungssystem, Auskunfts- und Bera- 
tungssystem ) : 

Enthält das zur Bewältigung der jeweiligen Aufgaben benötig- 
te Wissen (Beispiel: Wissen über Dialogformen in der Dialog- 
schicht). 
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( 2 ) Wissensquelle , die das Selbstbild der .jeweiligen Schicht 
enthält : 

Enthält Wissen über benötigte und/oder vorhandene Ressour- 
cen. Es handelt sich um relativ statisches Wissen, das im 
wesentlichen bei Konfigurationsänderungen modifiziert oder 
ausgetauscht wird (Beispiel: Wissen über die vorhandenen 
E/A-Geräte in der E/A-Schicht ) . 

( 3 ) Wissensquelle, die das Benutzer-Modell der .jeweiligen 
Schicht enthält : 

Enthält Wissen über den jeweiligen Benutzer bezogen auf die 
einzelne Schicht (Beispiel: Präferenz des Benutzers für 
Spracheingabe in der E/A-Schicht). 

( 4 ) Wissensquelle, die die vereinbarten Konventionen der jewei- 
ligen Schicht enthält: 

Enthält Wissen über vereinbarte Konventionen bez. des jewei- 
ligen Aufgabengebiets. Im Gegensatz zu Intentionen des Be- 
nutzers sind Konventionen mehr statisch und gelten über meh- 
rere Sitzungen hinweg. (Beispiel: Individuell festgelegtes 
Bildschirmlayout, das zu Beginn jeder Sitzung ausgegeben 
wird) . 

( 3 ) Wissensquelle, die die Intentionen des Benutzers der jewei- 
ligen Schicht enthält: 

Enthält Wissen über vereinbarte oder ermittelte Intentionen 
bez. des jeweiligen Aufgabengebietes. Im Gegensatz zu Kon- 
ventionen beschreiben Intentionen temporäre aufgabenbezo- 
gene Zielsetzungen des Benutzers. (Beispiel: Beim wiederhol- 
ten Ausfüllen eines Formulars während einer Sitzung über-, 
springt der Benutzer immer zwei E i ngabe f e 1 de r . Das Aus- 
kunfts- und Beratung s system fragt daraufhin, ob bei der wei- 
teren Eingabe diese Felder automatisch übersprungen werden 
sollen. ) 

( 6 ) Wissensquelle, die die Intentionen der jeweiligen Schicht 
selbst enthält : 

Enthält Wissen über Intentionen im jeweiligen Aufgabenge- 
biet der betreffenden Schicht. (Beispiel: Nicht mehrmals in 
einer Sitzung dem Benutzer denselben Rat geben). 
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3 Das "blackboard" -Konzept 

Neben der statischen Architektur (siehe Abb. 1) wird 
noch eine Kont rollarchi tektur benötigt, die eine geeignete Kom- 
munikation zwischen den im letzten Abschnitt aufgeführten Wis- 
sensquellen ermöglicht. 

Klassische Kontrollarchitekturen, die einen festen Kon- 
trollfluß zwischen einzelnen Komponenten vorsehen - wie bei der 
Architektur eines Compilers oder der 

ISO-OSI-Schichtenarchitektur - scheiden wegen der nicht antizi- 
pierbaren Kont rol 1 f lußstruktur innerhalb der E/A, des Dialogs, 
der Anwendungssysteme und des Auskunfts- und Beratungssystems 
aus . 

Diese klassischen Architekturen sind dadurch gekennzeich- 
net, daß 

- das Problem gut strukturierbar ist, 

- der Kontrollfluß zwischen fest definierten Komponenten statt- 
findet , 

- alle Komponenten immer vollzählig zur Problemlösung gebraucht 
werden , 

- die Anzahl der Komponenten auf eine relativ kleine Zahl be- 
grenzt ist. 

Diese Voraussetzungen liegen bei der MCS-AS-Archi tektur 
nicht vor. 

Als geeignetes Konzept kommt das bei Expertensystemen 
verwendete "blackboard"-Konzep t in Betracht. Dieses erlaubt die 
Kommunikation, Kooperation, Koordination, Synchronisation, 
Steuerung und Kontrolle von unabhängigen Wissensquellen durch 
die Verwendung einer globalen, zentralen und strukturierten 
Datenbasis ("blackboard"), um Probleme zu lösen, zu denen die 
einzelnen Wissensquellen Beiträge leisten können. 

Die Wissensquellen stellen Bereichsexperten dar, die dar- 
auf spezialisiert sind, in einem bestimmten Anwendungsbereich 
Spez i a 1 au f gäbe n zu lösen. Sie kommunizieren, indem sie Meldun- 
gen auf die Tafel schreiben und von anderen Bereichsexperten 
geschriebene Meldungen lesen. Die "blackboard" selbst ist pas- 
siv, d. h. sie dient nur als Kommunikationsmedium. Die Kommuni- 
kation zwischen dem Bereichsexperten über das Medium "black- 
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board" läuft jedoch nicht autonom ab, sondern wird durch eine 
Kontroll- und Steuerungsinstanz (scheduler) überwacht. 

Das "blackboard"-Konzept wurde für Expertensysteme ent- 
wickelt. Bei den folgenden vier Expertensystemen wird dieses 
Konzept in unterschiedlicher Form verwendet und determiniert 
die Exper tensy stem-Archi tektur : 

- HE ARSAV-I I / 4/ , 

- HEARSAY-1 1 1 /l/, /5/, /7/, 

- AGE /8/ , 

- BB1 /6/ . 

Die Weiterentwicklungen des HEARSAY- 1 1 -Konzeptes lassen 
sich insbesondere dadurch charakterisieren, daß das " domain "- 
Wissen von dem "control"- bzw. "scheduling "-Wissen explizit 
getrennt wird, sowohl durch getrennte Wissensquellen als auch 
durch eine geteilte "blackboard". 

Die damit verbundenen Vorteile sind: 

- transparente "schedul ing"-Schemata , 

- extreme Flexibilität, um unterschiedliche Schemata einzuset- 
zen . 

Als Nacht ei 1 muß man einen Effizienzverlust in Kauf neh- 
men . 



Die Vorteile wiegen den Nachteil für eine MCS-AS-Archi- 
tektur jedoch auf. Insbesondere für die Prototypentwicklung ist 
es notwendig, flexible "scheduling "-Schemata experimentell zu 
evaluieren . 

4 Die MCS-AS-Architektur 



Aufgrund der in den vorigen Abschnitten aufgeführten Ar- 
gumente ergibt sich die in Abb. 2 dargestellte statische Ge - 
samt archi tektur. 



Die MCS-AS-Gesamtarchitektur gliedert sich in drei 
Schichten: die E/A-Schicht, die Dialog-Schicht und die AS- 
"Schicht" . 
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Abb. 2: Statische Gesamtarchitektur (ohne Auskunfts- und Bera- 
tungssystem ) 
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Die E/A-Schicht löst alle E/A-geräte abhängigen MCS-Pro- 
bleme, die Dialog-Schicht löst alle E/A-qeräte una bhänqiqen MCS- 
Probleme und in der AS-" Schicht" werden alle AS-spezifischen 
Probleme gelöst. Von AS-" Schicht " zu sprechen ist daher nicht 
ganz korrekt. Es handelt sich um eine Ansammlung singulärer 
und/oder integrierter und/oder verteilter Anwendungssysteme, 
die ihre Aufgaben allein und/oder in Kooperation mit anderen 
Anwendungssystemen ausführen, während die Aufgaben für die E / A - 
und Dialog-Schicht festliegen. 

Gegenüber der Dialog-Schicht stellt sich die Ansammlung 
von Anwendungssystemen jedoch wie eine Schicht dar. 

Jede Schicht besteht aus einer "blackboard", die sich in 
eine "control-blackboard" und eine "domain-blackboard" glie- 
dert. Um die jeweilige "domain-blackboard" sind die in Ab- 
schnitt 2 beschriebenen Wissensquellen angeordnet. 

Um die "control blackboard" sind "control"-Wissensquel- 
len angeordnet; ihre Anzahl kann unterschiedlich sein, minimal 
gibt es zwei. Eine "control "-WQ ist für die Steuerung parallel 
vorliegender Aufträge zuständig (globale "control "-WQ genannt), 
eine zweite " control "-WQ ist für die Steuerung des Wissensquel- 
len-Einsatzes eines Auftrags zuständig (lokale "control"-WQ ) . 
Jede Schicht besitzt einen "base scheduler", der ausgewählte 
Wissensquellen aktiviert. 

Die AS-"Schicht" unterscheidet sich insofern von cfen 
anderen Schichten, als sie in Abhängigkeit von der Anzahl der 
Anwendungssysteme eine größere Anzahl von Wissensquellen um- 
faßt . 



Das Auskunfts- und Beratungssystem (AUS&BES) wird eben- 
falls als eine "Schicht" angesehen und besitzt eine analoge Mi- 
kroarchitektur wie die E/A-, Dialog- und AS- "Schicht". 

Die Dynamik der Gesamt architektur sieht folgendermaßen 

aus : 

- Die E/A-Schicht kommuniziert mit dem Benutzer und der Dialog- 
Schicht . 
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- Die Dialog-Schicht kommuniziert mit der E/A-Schicht und der 
AS- "Schicht" . 

- Die AS- "Schicht" kommuniziert mit der Dialog-Schicht. Über 
spezielle Anwendungssysteme können die einzelnen Anwendungs- 
systeme mit Anwendungssystemen auf anderen Computersystemen 
kommmunizieren . Außerdem können die Anwendungssysteme eines 
Computersystems - soweit vorgesehen - untereinander kommuni- 
zieren. 

Zwischen der E/A-Schicht und der AS- "Schicht" ist keine 
direkte, sondern nur eine indirekte Kommunikation über die Dia- 
log-Schicht möglich. 

Durch diese Kontrollarchitektur werden die Kommunika- 
tionsflüsse kanalisiert und die Entscheidungen dezentral bei 
der Instanz getroffen, die für das jeweilige Problem kompetent 
ist (Entscheidungskaskade). 

Jede Schicht kann an ihre Nachbarschicht Aufträge zur 
Bearbeitung übergeben. Der übergebene Auftrag wird dann von der 
entsprechenden Schicht autonom und asynchron bearbeitet. Auf- 
träge können auch als Probleme angesehen werden, die die Nach- 
barschicht, die dafür die Problemlösungskompetenz besitzt, zur 
Lösung übergeben werden. 

Ein Auftrag wird auf der "domain-blackboard" der entspre- 
chenden Schicht bekannt gemacht. Zur Veranschaulichung wird im 
folgenden davon ausgegangen, daß ein Auftrag die Form eines 
"frames" mit einer Anzahl von "slots" besitzt (Abb. 3). Jedes 
"slot" besteht aus einem "slot"-Namen und einem "slot"-Inhalt . 
Jeder "frame" besteht aus zwei Teilen, einem allgemeinen Teil 
mit "slots", der für jede Schicht gleich ist, und einem schicht- 
spezifischen "slot "-Teil. 

Wird eine Wissensquelle getriggert und sind die "precon- 
ditions" erfüllt, dann wird ein "activation record" erzeugt und 
auf der "control blackboard" eingetragen. 



Ein "activation record" besteht aus folgenden Informatio- 
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nen : 

- Absender, d. h. Wissensquellen-Name; bei Anwendungssystemen 
auch Anwendungssy stem-Name , 

- Art des Auftrags, 

- Priorität, 

- zusätzlichen Informationen. 



Eine "control"-Wissensquelle kann die "domain black- 
board" und die "control blackboard" lesen, "activation records" 
ändern (z.B. Priorität) und eigene eintragen. 



Der "base scheduler" aktiviert den "activation record" 
mit der jeweils höchsten Priorität. Nachdem ein "activation 
record" ausgewählt und die entsprechende Wissensquelle akti- 
viert wurde, wird der "activation record" gelöscht. 



Zur 1 'control ttacfcboartf 




allgemeiner 
’Slof-Teil für 
alle Schichten 



spezieller 
’Slof-Tel, 
unterschiedlich 
für jede 
Schicht 



0 ) (2} (3) = zeitlicher AWauf 



Abb . 3: Prinzipieller Aufbau eines Auftrags in " f rame/s lo t " - 
Darstel lung 



Es ist nicht möglich, daß sich Wissensquellen selbst 
gegenseitig direkt aufrufen. Ein Auftrag für eine Schicht kann 
von den Nachbarschichten kommen oder von einer Wissensquelle 
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der eigenen Schicht. 

Sobald ein Auftrag aus einer anderen Schicht auf der 
"domain blackboard" eingetragen wird, sind auch die schichtspe- 
zifischen "slots" der Absenderschicht lesend sichtbar. 

Wurde ein Auftrag durch eine Wissensquelle der eigenen 
Schicht bearbeitet, dann kann daraus ein neuer Auftrag entste- 
hen, den der "base scheduler" an die Nachbarschichten weiter- 
gibt. Die Weitergabe an die Nachbarschicht wird vorgenommen, 
wenn sich keine Wissensquelle der eigenen Schicht mehr meldet 
und einen Beitrag anbietet. In einem solchen Fall aktiviert der 
"base scheduler" nicht eine Wissensquelle der eigenen Schicht, 
sondern aktiviert eine Nachbarschicht, indem er den Auftrag auf 
der "domain blackboard" der entsprechenden Nachbarschicht ein- 
trägt. Für die Nachbarschicht unterscheidet sich der Eintrag 
nicht von einem Eintrag, den eine eigene Wissensquelle ein- 
trägt. 




Abb. 4: Verwaltung mehrerer Aufträge durch dreidimensionale 
"blackboard "-Architektur 

Sollen nun zu einem Zeitpunkt mehrere Aufträge auf der 
"blackboard" eingetragen werden, so kann dies von der Architek- 
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tur her auf zwei Arten gelöst werden: 

(a) Es gibt eine War t eschiange , in der anstehende Aufträge ein- 
getragen werden. Aufgrund der Einträge in der "control 
blackboard" wird entschieden, welcher Auftrag nach Freigabe 
der "domain blackboard" eingetragen wird. 

(b) Jede "blackboard" kann man sich dreidimensional v/orstellen 
(Abb. 4). Entsprechend der Anzahl der Aufträge wächst oder 
schrumpft die dritte Dimension. 

Im folgenden wird von dem Architekturkonzept (b) ausge- 
gangen, da es eine optimale Nutzung vorhandener Ressourcen er- 
möglicht . 

Die globale "control "-Wissensquelle koordiniert die Akti- 
vierung der einzelnen Aufträge. 

Tab. 1 zeigt, welche "slots" vorhanden sind. 

Folgende Au ft raqsarten sind möglich: 

• E inqabeau f t rag : 

Auftragsart, bei dem vom Adressaten Eingaben angefordert wer- 
den. Die Eingaben können ein breites Spektrum abdecken: Von 
der Eingabe einer Bestätigung bis hin zur Eingabe umfangrei- 
cher Informationen. Da mit Eingabe meist auch Ausgaben in 
Form von Texten, Voreinstellungen usw. verbunden sind, 
schließt ein Eingabeauftrag Ausgaben jeglicher Form mit ein. 

• Ausqabeauftraq: 

Auftragsart, bei der dem Adressaten Ausgabe Informationen gege- 
ben werden, ohne daß von ihm eine Rückmeldung erwartet wird. 

• Aktionsau ft rag: 

Auftragsart, bei der der Adressat aufgefordert wird, eine 
spezifische Aktion durchzuführen. 

• Informationsauftraq: 

Auftragsart, bei der der Adressat Informationen vom Absender 
erhält oder aufgefordert wird, dem Absender Informationen zu 
liefern. Zur Übergabe von Informationen wird der "slot" Infor- 
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mationen verwendet. Da die Feinstruktur des Informationsteils 
schichtenabhängig ist, ist der Informationsteil nicht bei den 
allgemeinen "slots” aufgeführt. 



Bei Eingabe-, Ausgabe- und Aktionsaufträgen verwendet 
die AU5&BES-" Schicht" dieselben schichtenspezifischen "slots" 
wie die AS-"Schicht " . 



"slot"-Name 


Kommentar zum Inhalt 


Schicht 


Adressat 


Name der Ziel-Schicht; bei der 
AS-"Schicht" auch Name des AS; 
bei anderem CS auch CS-Name 




Absender 


Name der Schicht; bei der AS- 
"Schicht" auch Name des AS; kann 
nicht geändert werden. 




Art des Auftrags 


Auswahl einer Auftragsart aus 
einer festgelegten Menge von 
Auftragsarten 




Priorität 


Priorität des Auftrags; Vorbe- 
legung erfolgt durch Absender 


alle 

Schichten 


Auftragsstatistik 


Zeitl. Anfang & Ende des 
Auftrags oder der dabei abge- 
wickelten Teilaufträge; beteilig- 
te WQ und Schichten 




Name der Aktion 


Name der auszuführenden oder 
betreffenden Aktion/Operation/ 
Funktion 




Name des Objekts 


Name des zu manipulierenden oder 
betroffenen Objekts/Datums/ 
Datenstruktur 




Anwenderprofil 


Angaben zum Profil des Anwenders 




Objektbeschreibung 


Struktur, Typ und sonstige 
Angaben zum Objekt 


AS-"Schicht" & 
AUS&BES- "Schicht" 


Folgeaufträge 


Aufträge, die im Anschluß an 
diesen Auftrag zu initieren sind 


In format ionsteil 
(wird vom AUS&BES 
ausgewertet ) 


Informationen 





Tab . 1 



slot"- Inhalte , Teil 1 
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"slot"-Name 


Kommentar zum Inhalt 


Schicht 


Benutzerprofil 


Angaben zum Profil des Benutzers 




Dialogform 


Name der Dialogform 


Dialog-Schicht 


Layout 


Basislayout für die E/A-Schicht 


Informationsteil 


Informationen 




Benutzerprofil 


Angaben zum Profil des Benutzers 




E/A-Form 


Name der E/A-Form z.B. direkte 
Manipulation 




E ingabegerät ( e ) -WQ 


Name des oder der Eingabegeräte- 
WQ 




Ausgabegeräte ( e ) -WQ 


Name des oder der Ausgabegeräte- 
WQ 


E/A-Schicht 


E/A-Attribute 


Attribute die von den jeweiligen 
E/A-Geräte-WQ oder E/A-Werkzeug- 
WQ zu beachten sind. 




E/A-Bereitschaft 


Anzeige, welche E/A-Geräte-WQ 
oder E/A-Werkzeug-WQ zur Eingabe 
und/oder Ausgabe bereit ist 




Informat ionsteil 


Informationen 




Benutzerprofil 


Angaben zum Profil des Benutzers 




Informat ionsteil 


Enthält aufbereitete Informa- 
tionen 




Informationsaufträge 


Aufträge, die zu initiieren sind, 
um benötigte Informationen zu 
erhalten. Es ist der Name der 
Schicht bzw. bei der AS-"Schicht" 
der AS-Name anzugeben, von der 
die Information benötigt wird. 

Der vorliegende Auftrag bleibt 
aktiv, bis Informationsaufträge 
abgeschlossen sind. 


AUS&BES-" Schicht" 



T ab . 



slot "-Inhalte, Teil 2 
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5 Charakteristika der vorqeschlaqenen Architektur 

Aus der Sicht der Software-Ergonomie weist die Architek- 
tur folgende Charakteristika auf: 

- Höchstmögliche Flexibilität. 

- Modularisierung des software-ergonomischen Wissens. 

- Extensive Metakommunikation möglich. 

- Software-ergonomische Experimente durchführbar durch Entfer- 
nen und Hinzufügen von Wissensquellen sowie durch Einbringen 
von "high level control concepts". 

- Gestaltungswünsche können durch unterschiedliche Maßnahmen 
verwirklicht werden, z. B. durch Konventionen oder Intentio- 
nen . 

- Autonomes Auskunfts- und Beratungssystem. 

Aus der Sicht des Software Engineering weist die Archi- 
tektur folgende Charakteristika auf: 

- Strukturierte statische Makro- und Mikroarchitektur. 

- Strukturierte Makro- und Mikro-Kontrollarchitektur . 

- Modulare Architektur durch autonome Wissensquellen. 

- Jede Wissensquelle besitzt spezifizierte Schnittstellen. 

- Vorhandene traditionelle Werkzeuge und Anwendungssysteme kön- 
nen angepaßt werden, da Kommunikation mit der "blackboard" 
nur über explizite Schnittstellen erfolgt. 

- Architektur erlaubt hardwaremäßige Unterstützung z. B. durch 
Prozessoren . 

- Inkrementelle Entwicklung und "rapid prototyping" sind mög- 
lich. 

- Erstmals Anwendung des "blackboard"-Konzepts für eine MCS-AS- 
AUS&BES-Architektur . 

- Erstmals vier "blackboards", die nebeneinander angeordnet 
sind und miteinander kommunizieren. 

- Dreidimensionale "blackboard". 



6 Zur Implementierung 

Die beschriebene Architektur wurde in zwei exemplari- 
schen Implementierungen evaluiert. 
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Auf einem Arbeitsplatzrechner mit einem modifizierten 
XENIX-Betriebssystem wurden in der Programmiersprache C die 
E/A-, Dialog- und Anwendungssystem-Schicht realisiert /9/. Die 
Kommunikation zwischen den Schichten wurde durch unabhängige 
Prozesse und "Pipes" verwirklicht. Die gesamte Architektur 
wurde in eine bestehende Systemarchitektur eingebettet; vorhan- 
dene Werkzeuge (hier: Fenstersystem) wurden benutzt. 

Die Implementierung hat neben der Realisierbarkeit des 
Architekturkonzepts gezeigt, daß die Aufgabenverteilung zwi- 
schen den Schichten sinnvoll ist. Der Anwendungsentwickler wird 
durch die vorgenommene Aufgabenverteilung von der Mensch-Compu- 
ter-Interaktion wesentlich entlastet, die Portabilität der An- 
wendungssysteme wird entscheidend verbessert. 

Die zweite exemplarische Implementierung erfolgte auf 
einer Symbolics-Lisp-Maschine in LISP und PROLOG unter Verwen- 
dung des F 1 avor - Sy s tem s /10/, /ll/. Als Anwendungsbereich für 
die Dialogschicht wurde eine Komponente zur Eingabe natürlich- 
sprachlicher Anfragen an Wissensbasen realisiert. In Abhängig- 
keit von der Benutzerkompetenz, dem Benutzerverhalten, den fest- 
gelegten Konventionen und der aktuellen Benutzungssituation er- 
hält der Benutzer entsprechende Hilfeleistungen angeboten. 

Die Implementierung hat gezeigt, daß eine objektorien- 
tierte Realisierung der Architektur möglich ist, und daß das 
"blackboard"-Konzep t einen geeigneten Mechanismus zur Kommunika- 
tion zwischen den Wissensbasen zur Verfügung stellt. Das 
"message passing" des Flavor-Systems reicht nicht auf, um eine 
hohe statische Modularität der Wissensbasen sicherzustellen. 
Außerdem stellt es kein vollständiges Paradigma für Inferenzpro- 
zesse dar. Dies scheinen generell Schwächen objektorientierter 
Sprachen zu sein . 
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Eine Intelligente Schnittstelle 
zur Ankopplung Technischer Prozesse 
an ein Experten-System* 

H. Carls 

Als Ansatz zu einem Echtzeit-Expertensystem wird eine Intelligente Schnittstelle vorgestellt, die 
die Ablaufumgebung für einen Expertensystem kern bildet und gleichzeitig die Verbindung zu 
den Meßsignalen des technischen Prozesses herstellt. Über das zugrunde liegende Architektur- 
konzept einschließlich der Parametrierungsoberfläche der Schnittstelle wird berichtet. 

1. Einführung 

Expertensysteme in der Prozeßführung unterscheiden sich von herkömmlichen, dialogorien- 
tierten Systemen durch die direkte Ankopplung an eine technische Anlage. Daraus ergeben sich 
einige Besonderheiten. Zum einen sind die Daten, auf deren Grundlage eine Expertise durch- 
geführt wird, veränderlich, zum anderen ist zu fordern, daß die Inferenzprozessse in ver- 
nünftigen Zeiten Ergebnisse liefern. Daneben ist der unterschiedliche Abstraktionsgrad der zur 
Verfügung stehenden Eingangsdaten von Bedeutung. Während in einem dialogorientierten 
Expertensystem die Kommunikation mit der Umwelt, d.h. mit dem Benutzer, auf der Basis 
abstrakter Begriffe erfolgt, stellt eine technische Anlage nur elementare Signale zur Verfügung. 
Inferenzsysteme arbeiten für gewöhnlich mit komplexeren Daten; es ergibt sich daher die Not- 
wendigkeit der Datenaufbereitung und Aggregation. Aus Signalen müssen Zeichen und Sym- 
bole, d.h. Information abstrakterer Bedeutung gebildet werden [ 1-3 ] 

Die Intelligente Schnittstelle soll die Verbindung zwischen dem technischen Prozeß und dem 
eigentlichen Expertensystem kern, (Bearbeitung von Problemen mithilfe von Regeln und Logik ) 
hersteilen. 

Ihre Aufgaben sind : 

Datenerfassung von einem Prozeßleitsystem oder einer technischen Anlage 

Entkopplung der Datenerfassung vom eigentlichen Expertensystem, so daß zeitlich sich 

ändernde Daten weiter aktualisiert werden können 

Aufbereitung der Daten in Informationen höheren Abstraktionsgrades 

Identifikation von Prozeßzuständen durch Kombination und Interpretation von Prozeßdaten 

Anstoß und Koordination der Bearbeitung von Inferenzaufgaben 



*) BMFT-Verbundprojekt 

"TEX-I: Technische Expertensysteme zur Dateninterpretation, Diagnose und Prozeßführung " 
Projektpartner: Bayer AG, ESG, GMD, IITB, Interatom, Krupp Atlas EIektronik,Siemens AG 
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Optimierungsaufgaben wie: 

Reduzierung der Datenflut 

Anpassung der Datenerfassung an Betriebszustände des technischen Prozesses 
Vorverarbeitung der Prozeßdaten in einer für den Expertensystem kern geeigneten Art 
und Weise 

Formal besteht die Intelligente Schnittstelle aus Strukturen zur Beschreibung von Signalen und 
Situationsbildern (d.h. Zustandsbeschreibungen des physikalischen Prozesses) und aus Funk- 
tionen zu deren Bearbeitung. Für eine konkrete Anwendung müssen die Datentypen durch 
Instanziierung gefüllt und evtl, der Satz der Basismethoden zur Verarbeitung und Überwachung 
von Signalen und Situationen erweitert werden. 

Die Möglichkeit der programmgesteuerten on-line-Erzeugung von Situationen wird geprüft. 



2. Prozeßführunq 

In Untersuchungen von MENSCH-MACHINE-SYSTEMEN (Decision Support, Mental Models) wer- 
den technische Systeme häufig in einem Schichtenmodell dargestellt. [ 1-2 ] 

Die unterste Ebene, die physikalische Schicht, enthält die Komponenten, Aggregate, 
Baugruppen etc., des Prozesses. 

Auf der mittleren Ebene, in der funktionalen Schicht werden die Wechselwirkungen der 
verschiedenen Systemteile beschrieben; das können elektrische, mechanische und chemische 
Prozesse, Regelkreise und Bilanzen sein, durch die die Elemente der physikalischen Schicht in 
vielfältiger Weise verbunden und strukturiert sind. 

Auf der obersten Ebene, in der symbolischen Schicht werden die Ziele des technischen 
Systems dargestellt. (Optimierungsaufgaben, angestrebte Prozeßzustände etc.) Durch diese 
intentionalen Beschreibungen werden die Elemente der funktionalen Schicht in einen Sinn- 
und Zweckzusammenhang gebracht. 

Der physikalische Charakter nimmt von unten nach oben ab, während der Bedeutungsinhalt und 
der normative Charakter zunehmen. 

Nach [ 1 ] entsprechen den Schichten dieses Modells drei Typen der Informationsdarstellung : 



physikalische Schicht: 
funktionale Schicht: 
symbolische Schicht: 



Signale 

Zeichen 

Symbole 
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In Abb. 1 ist dieses Modell ( nach [ 2 ] ) mit zwei zusätzlichen Zwischenstufen dargestellt. Die linke 
Hälfte zeigt den hierarchischen Aufbau der Prozeßwelt, beginnend mit den Komponenten bis 
hin zu ganz allgemeinen Zielvorgaben wie Maximierung der Produktion, Minimierung des Ener- 
gieeinsatzes etc.. Im rechten Teil der Abbildung ist der unterschiedliche Ausprägungsgrad des 
physikalischen Anteils gegenüber den angestrebten Prozeßzielen schematisch wiedergegeben. 
Maßstäbe für das gewünschte Funktionieren sind aus dem Zweck des Systems zu entwickeln, d.h. 
Kriterien für Fehler und Störungen können nur vor dem Hintergrund des angestrebten Prozeß- 
ziels formuliert werden. In bestimmten Betriebszuständen oder -phasen sind z.B.AIarme bedeu- 
tungslos, Meßsignale besitzen je nach Fahrweise des Prozesses, unterschiedliche Soll- und 
Grenzwerte, etc.. Die Ursachen für Fehlverhalten oder Störungen kommen aus der physikalischen 
Welt (bottom up); die Kriterien zur Definition von Fehlverhalten lassen sich dagegen nur aus 
den Prozesszielen ableiten (top down). 



INTENTIONALE BESCHREIBUNG 

Produktions - Fluß - Modelle, 

Operations - Ziele 

ABSTRAKTE - FUNKTIONEN 

Kausale Struktur, Sollfunktionen, 

Masse- Energie- Bilanzen 

GENERELLE - FUNKTIONEN 

Standard Funktionen und Prozesse, 

Regel Kreise 

PHYSIKALISCHE - FUNKTIONEN 
elektrische, mechanische, chemische Pro- 
zesse von Komponenten u. Baugruppen 

PHYSIKALISCHE BESCHREIBUNG 
Räumliche Anordnung, Anatomie, 
Material und Form des Systems 




Abb. 1 Abstraktionsstufen eines technischen systems 
( nach Rasmussen/Goodstein ) 
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3. Konzept eines Echtzeit Expertensvstems 

In Anlehnung an diesen hierarchischen Aufbau der Prozeßwelt sollen in der intelligenten Schnitt- 
stelle geeignete Formalismen bereitgestellt werden. Primär-Signale und Abgeleitete Signale 
(einfache funktionale Abhängigkeiten) bilden die Prozeßinformation auf den unteren Ebenen. 
Sie repräsentieren die vom Expertensystem beobachtbare Außenwelt. Situationen oder 
Situationsbilder dienen zur Darstellung des angestrebten System zustandes auf den höheren 
Abstraktionsniveaus (autonome Funktionsgruppen oder Funktionsbereiche, Beschreibung der 
Prozessziele). Zum Zweck einer besseren Strukturierbarkeit sind die Situationen aggregierbar 
gestaltet; es läßt sich so eine Hierarchie von Ober- und Untersituationen aufbauen. 

Technische Systeme sind in der Regel dynamisch, d.h. die Signalwerte und damit auch die 
Situationszustände ändern sich laufend. Durch den Umstand, daß Situationen Wertebereichen 
von Signalen entsprechen, sind Änderungen zunächst einmal auf die Signalebene reduziert. So 
leisten Situationen eine Signalverdichtung nicht nur hinsichtlich der Signalmenge sondern auch 
über die Zeit. Treten Störungen, d.h. Normabweichungen auf, so können, ausgehend vom 
momentanen, quasistatischen Prozeßzustand, Diagnosen, Interpretationen, und Prognosen mit 
konventionellen Inferenzmaschinen durchgeführt werden. Die Probleme zeitlich sich ändernder 
Größen werden damit vermieden. Ein solches eingefrorenes Prozeßabbild mit dessen Bearbei- 
tung der Expertensystemkern beauftragt wird, soll im Folgenden Aktion genannt werden. 

Die Bearbeitung von Aktionen kann relativ viel Zeit beanspruchen, vor allem, wenn auch Dialoge 
(Fragen an den Benutzer und Fragen des Benutzers nach Erklärungen) stattfinden. Daher ist es 
sinnvoll, Aktionen als separate Rechenprozesse zu implementieren. Sie werden mit einem 
bestimmten Situationszustand gestartet und beeinträchtigen danach die Aktualisierung der 
Meßsignale nicht wesentlich. Bei einer späteren, gravierenden Änderung des Zustandes der 
Situation wird dann die Bearbeitung der nächsten Aktion gestartet, so daß mehrere Inferenz- 
aufgaben quasiparallel und miteinander konkurrierend ablaufen. Die Dringlichkeit der aus- 
lösenden Situation kann dabei als Kriterium zur Festlegung von Prioritäten dienen. Aktionen, die 
in Bearbeitung sind, lassen sich abbrechen, falls erkannt wird, daß die Daten auf denen die 
Aktion operiert, nicht mehr aktuell sind. Auf diese Weise wird eine Entkopplung zwischen 
Datenerfassung (Signale u.Situationen) und den Inferenzaufgabem erreicht. Lediglich Signale 
und Situationen müssen in Echtzeit verarbeitet werden. 

Situationsbilder können Umfang und Häufigkeit der eigenen Datenerfassung steuern. Während 
des normalen Prozeßablaufs werden nur die notwendigsten Signale vom Prozeß angefordert. In 
kritischen Zuständen wird die Erfassung der Signale erweitert oder beschleunigt und so eine 
Fokussierung erreicht. 
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4. Struktur der Intelligenten Schnittstelle 

Bei der Implementation der Intelligenten Schnittstelle waren zwei Randbedingungen zu 
beachten: 

Hardware- und Softwareumgebung sind die SYMBOUCS-LISP-Maschine und ein konven- 
tioneller Prozeßrechner, 

Der Expertensystemkern wird mithilfe des Werkzeugsystems BABYLON der GMD realisiert. 

Formal ist die Intelligente Schnittstelle eine Menge von LISP-Funktionen, die sich auf mehrere 
Rechenprozesse verteilen, zusammen mit Datenstrukturen, die anwendungsbezogen mit Inhalt 
zu füllen sind. Sie gliedert sich im wesentlichen in: 

Kommunikations-Modul 
Signal / Situations-Modul 
Monitor 



4.1 Kommunikations-Modul 

Der Kommunikationsmodul stellt die Verbindung zwischen der Intelligenten Schnittstelle und 
dem angeschlossenen Prozeßrechner her. Er besteht aus einer protokollunabhängigen 
Auftragsverwaltung und einem protokollspezifischen Teil, der die Kommunikationsfunktionen 
enthält. 

Ein eigenes Übertragungsprotokolls erwies sich als notwendig, da als einziges gemeinsames 
Kommunikationsmittel zwischen Symbolics und R30 eine serielle Datenleitung (RS 232) und nur 
primitive Zugriffsfunktionen bereitstanden. Bei der Protokolldefinition waren die Besonder- 
heiten der Prozeßrechnerkommunikation zu beachten, d.h.: 

hohe Datenrate, bei vielen, unkoordiniert auftretenden kurzen Datentelegrammen 

Punkt-zu-Punkt-Verbindung 

Interprozeßkommunikation. 

Die Initiative für den Empfang von Daten liegt jn jedem Fall bei der Intelligenten Schnittstelle. 
Die protokollunabhängige Auftragsverwaltung fordert Signale singulär oder zyklisch vom 
Prozeß an, oder nimmt, falls Empfangsbereitschaft besteht, sporadische Ereignisse ( sog. passive 
Signale) entgegen. Eine detaillierte Beschreibung dieses Moduls ist in [4] zu finden. 




399 



4.2 Signal- / Situations-Modul 

Der Signal /Situations-Modul ( Abb 2 ) bildet den Kern der Intelligenten Schnittstelle; in meh- 
reren Stufen stellt er ein dynamisches Modell des technischen Systems dar. 

Programmtechnisch enthält er drei Objekt-Klassen ( Mengen von instanziierten Strukturen ) : 
Primär-Signale, die die interne Repräsentation der Prozeßsignale bilden. 

Abgeleitete Signale, die Verknüpfungen von Primär-Signalen untereinander oder mit 
anderen abgeleiteten Signalen sind. Sie wurden eingeführt, um eine größere Flexibilität bei 
der Strukturierung des Prozeßabbildes zu erreichen. 

Situationen, das sind Zusammenfassungen von Meßwerten - und auf höheren Ebenen auch 
von anderen Situationen - nach funktionellen und / oder strukturellen Gesichtspunkten. Zu 
jedem Meßwert können situationsspezifische Überwachungsmethoden und Parameter ange- 
geben werden. 
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Für die Berechnung der Abgeleiteten-Signale und für die Überwachung der Situationen steht 
jeweils ein eigener Rechenprozeß (Signal-Verarbeitung, bzw. Zustands- Interpreter) zur Verfü- 
gung, 

Meßsignale werden entweder als passive Signale (datengetrieben, d.h. Alarme, Interrupts) vom 
Prozeß an die Schnittstelle geschickt, oder als aktive Signale (zielgetrieben) durch die Schnitt- 
stelle vom Prozeß angefordert, wobei die Anforderung sporadisch oder periodisch erfolgen 
kann. Wir unterscheiden hier aktiv und passiv, je nachdem ob die Initiative zur Aktualisierung 
bei der intelligenten Schnittstelle liegt oder nicht. In jedem Fall muß das Signal zunächst durch 
eine ":ON-Methode" in einen empfangsbereiten Zustand gebracht werden. Nach der Erfassung 
werden die Meßwerte einer Verarbeitung unterzogen, evtl, durch Kombination mit anderen 
Signalen, in abgeleitete Werte umgerechnet und in Situationsbildern zusammengefaßt. Mit dem 
Formalismus der abgeleiteten Signale lassen sich die unteren Hierarchieebenen des Prozeß- 
modells nach Abb. 2 realisieren. Fehlermuster und Störungen des Prozesses, die sich aus bestimm- 
ten, vorhersehbaren Ereignissen oder als Kombination bestimmter Werte zusammensetzen, 
können auf diese Weise beschrieben werden, ebenso Frühwarnungen, als Extrapolation unter 
Zugriff auf eine Signal-History. Die Behandlung von ungenauen Werten, die Berechnung von 
Gewichtsfaktoren oder Wahrscheinlichkeiten für das Vorliegen von Störungen kann ebenfalls 
mit abgeleiteten Signalen erfolgen. 



5. Signale 

Signale werden als Objekte der Typs PRIMAER-SIGNAL oder ABGELEITETES-SIGNAL instanziiert. 
Beide enthalten den Typ SIGNAL als Komponente. 



SIGNAL WERT 

ZEIT 

ZYKLUS-ZEIT 

EXPORT-LISTE 



HISTORY-LENGTH 

HISTORY 

UEBERWACHUNGS-VORSCHRIFT 

UEBERWACHUNGS-PARAMETER 



WERT enthält den aktuellen Wert des Signals, möglich sind prinzipiell beliebige LISP-Ausdrücke, 
insbesondere natürlich Zahlen und Symbole. 

ZEIT enthält den Zeitpunkt, zu dem WERT ermittelt wurde. 

ZYKLUS-ZEIT enthält den Anforderungszyklus in Sekunden, falls dieses Signal vom Typ aktiv ist . 
Es handelt sich dabei um einen Default-Wert, der durch die in einer Situation angegebenen 
Zykluszeit überschrieben werden kann. 

EXPORT-LISTE enthält die Namen derjenigen abgeleiteten Signale oder Situationen, die von 
einer Signaländerung benachrichtigt werden müssen. 
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HISTORY ist eine Liste von WERT-ZEIT-Paaren die angelegt wird, wenn HISTORY-LENGTH > 1 

Nach dem Eintrag eines neuen Wertes kann dieser mit speziellen Parametern anhand einer Über- 
wachungsvorschrift überprüft werden. Normabweichungen werden an alle aktiven Situationen 
geschickt, die dieses Signal als Eingangssignal enthalten. Die hier angegebene Überwachungs- 
vorschrift und Parameter sind Defaultwerte, die durch Spezifikationen in einer Situation über- 
schrieben werden. 



PRIMAER-S1GNAL ERFASSUNGS-TYP 

IDENTIFIKATOR 



VERARBEITUNGS-VORSCHRIFT 

VERARBEITUNGS-PARAMETER 



ERFASSUNGS-TYP kennzeichnet die Art der Erfassung des Signals. 

AKTIV bedeutet, daß das Signal von der Intelligenten Schnittstelle beim Prozeßleitsystem 
angefordert werden kann, 

PASSIV heißt, daß das Signal nur empfangen werden kann, (Ereignisse Alarme ) 
IDENTIFIKATOR enthält die Angabe einer Kennung, mit der der physikalische Prozeß das entspre- 
chende Meßsignal adressiert, wenn eine Adressierung über den Signalnamen nicht möglich oder 
unzweckmäßig ist. 

Die VERARBEITUNGS-VORSCHRIFT eines Signals wird zusammen mit den VERARBEITUNGS- 
PARAMETERN auf den vom Prozeß empfangenen Rohwert angewendet und liefert den eigent- 
lichen Signalwert. Hier sind z.B. Kennlinienberechnungen, Filterungen etc. möglich. 



ABGELEITETES-SIGNAL 



IMPORT-LISTE 
ABLEITUNGS-VORSCHRIFT 
ABLEITU NGS-PARAM ETE R 



IMPORT-LISTE ist eine Liste derjenigen Primären oder Abgeleiteten Signale, aus denen der Wert 
des Objekts mithilfe der Ableitungsvorschrift und der Ableitungs-Parameter berechnet wird. 

Die Aufteilung in Objekte und in einen Satz von Methoden zur Bearbeitung bzw. Kombination 
der Objekte gewährleistet Modularität und Übersichtlichkeit der Programme. 
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6. Situationen 

Situationsbilder oder Situationen erfüllen neben einer Datenabstraktion folgende Aufgaben: 
Störungen, die gleiche funktionale Bereiche betreffen und die wahrscheinlich auch gleiche 
oder ähnliche Ursachen haben, werden gesammelt und für eine festgelegte Zeit gepuffert, 
bis der Zustand der Situtation hinreichend klar ist; der Expertensystem kern muß also nicht 
bei jedem einzelnen Alarm oder jeder Normabweichung eines Meßwertes aktiviert werden. 
Später eintreffende Störungen können einer Situation zugeordnet werden, die bereits eine 
Aktion ausgelöst hat und brauchen nicht zu neuen Aktionen zu führen. 

Da Situationen bestimmte Zustände eines technischen Systems repräsentieren, kann die 
Prozeßsigna lerfassung und Überwachung den Systemzuständen angepaßt werden. So lassen 
sich bestimmte Meßwerte häufiger aktualisieren als andere oder situationsabhängig völlig 
unterdrücken. Dadurch kann die gesamte Prozeßsignalerfassung optimal gesteuert werden. 

Einfache Situationsbilder enthalten vor allem Listen von Signal-Namen sowie Überwachungs- 
methoden und deren Parameter. Ist für mindestens einen dieser Meßwerte (primärer oder abge- 
leiteter Wert) das "Normal" Kriterium nicht mehr erfüllt, so gilt die Situation als gestört. 
Situationen können hierarchisch strukturiert werden (Ober/Unter-Situationen); es besteht dabei 
die Möglichkeit, die Aktivierung der Unter-Situationen zeitabhängig oder ereignisabhängig zu 
steuern. 

Es gibt also: 

Untersituationen, die immer aktiviert werden, wenn die betrachtete Situation aktiv ist. 
Untersituationen, die zu bestimmten Zeitpunkten oder in bestimmten Intervallen evtl, für 
eine festgelegte Zeitdauer aktiviert werden ( Kontrollgang des Operateurs, täglicher Test 
einer Baugruppe) und 

Untersituationen, die in Abhängigkeit von bestimmten Signalzuständen aktiv sind. 



Situationen werden als Objekte von folgendem Typ implementiert: 



SITUATION ZUSTAND IMPORT-MELDE-LISTE 

ZEITFENSTER OBER - SITUATIONEN 

MELDUNGS - SCHLANGE UNTER - SITUATIONEN 



Mögliche ZUSTÄNDE einer Situation sind RUHEND oder AKTIV, wobei der Zustand aktiv drei 
Unterzustände besitzt : 

NORMAL, d.h. alle Eingangssignale dieser Situation werden erfaßt und überwacht. ( Die 
Namen finden sich in der IMPORT-MELDE-LISTE.) 
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TIME-OUT, d.h. die Überwachungsvorschrift eines Eingangssignals hat eine Normab- 
weichung festgestellt und eine Zeitüberwachung für diese Situation läuft. 

GESTOERT, d.h. die Zeitüberwachung ist abgelaufen und eine Überwachungsvorschrift der 
Signale der IMPORT-MELDE-LISTE liefert immer noch eine Grenzwertverletzung oder einen 
Alarm. 

Aktiv wird eine Situation, wenn sie als Untersituation einer aktiven Situation auftritt und ihre 
entsprechende Aktivierungsbedingung erfüllt ist (siehe Untersituationsliste). Eine ausgezeich- 
nete TOP-LEVEL- Situation ist immer aktiv. 

ZEITFENSTER , Länge der Wartezeit, bevor die Störung der Ober-Situation (en) gemeldet wird. 

MELDUNGS-SCHLANGE, eine Liste von Listen 

(Name-des-Signals/der-Situation Störgrund Zeit) 

IMPORT-MELDE-LISTE beschreibt die zu einer Situation gehörenden Signale. Neben dem 
Signalnamen können durch Keyword-Value-Paare Parameter angegeben werden, die eine 
situationsspezifische Erfassung und Überwachung des betreffenden Signals bewirken; 
außerdem kann der Erfassungszyklus vorgegeben werden. Fehlen diese Angaben, so werden 
die beim Signal stehenden Defaultwerte verwendet. Falls die Situation aktiv ist, werden die 
Signale der Import-Melde-Liste entweder mit den spezifizierten Vorschriften und Parametern 
oder mit den Defaultwerten überprüft. Liefert der Test NON - NIL, so wird die time-out- 
Behandlung der Situation gestartet. 

OBER - SITUATIONEN, eine Liste der Namen der übergeordneten Situationen 

UNTER - SITUATIONEN, eine Liste von Listen der untergeordneten Situationen, bestehend aus 
Prädikat und Situations-Name (Situations-Name kann auch eine Liste von Namen sein). 
Prädikat ist entweder: 

T : die Situationen der folgenden Liste werden immer aktiviert, wenn die betrachtete 
Situation aktiv gemacht wird. 

eine Lisp-Form, die spezielle Ausdrücke wie AT, AFTER, ALL, DURING, etc mit 
zugehörigen Zeitangaben enthält : Die Situationen der dann folgenden Liste werden 
dem Scheduler des Prozesses ZUSTANDS-INTERPRETER übergeben und dort verwaltet 
(:ON oder :OFF geschaltet). 

ein Lisp-Ausdruck von der Form der Einträge in der IMPORT-MELDE-LISTE .In diesem Fall 
werden die Unter-Situationen nur dann aktiviert, wenn die Überwachungsvorschrift des 
Signals, unter Verwendung der mitgelieferten Parameter, eine Normabweichung 
ergibt. 
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Der Modul Monitor steuert und koordiniert die Bearbeitung der Aktionsbilder durch Festlegung 
von Prioritäten sowie durch Unterbrechen und Wiederstart. Die eigentliche Diagnose und Inter- 
pretation der Aktionen wird vom Kernsystem durchgeführt. Abb. 3 zeigt den Gesamtablauf 
schematisch. 




Abb. 3 Schematischer Aufbau der Intelligenten Schnittstelle 



7. Zusammenfassung 

Zielsetzung der Arbeit ist die Entwicklung von technischen Expertensystemen als integrierte 
Einheiten in der Prozeßführung. Durch ein Interface - die Intelligente Schnittstelle - wird die 
Anwendung klassischer dialogorientierter Expertensysteme auf dynamische technische Prozesse 
ermöglicht. Die Schnittstelle dient der Erfassung und Verarbeitung zeitabhängiger Prozeß- 
signale; durch räumliche und zeitliche Integration wird aus primitiven Eingangsdaten ein, sich in 
der Zeit nur noch langsam änderndes Prozeßabbild höherer Abstraktion aufgebaut, und dann an 
den Expertensystem kern zur endgültigen Bearbeitung übergeben. Neben der Datenerfassung 
koordiniert die Intelligente Schnittstelle konkurrierende Schlußfolgerungsprozesse durch Ver- 
gabe von Prioritäten sowie durch Unterbrechen und Wiederstart. Realzeitangepasstes Verhalten 
wird ermöglicht, da parallel zur Bearbeitung der Aktionen die Prozeßsignale und Situationen 
aktualisiert werden. 
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PLAKON 

EIN ÜBERGREI FENDES KONZEPT 
ZUR WISSENSREPRÄSENTATION UND PROBLENLÖSUNG 
BEI PLANUNGS- UND KONFIGURIERUNGSAUFGABEN . 



Roman Cunis, Andreas Günter, Ingo Syska 



Schlüsselwörter : 

Konfigurierung, Planung und Entwurf, Wissensrepräsentation 



Zusammenfassung: 

Wir fassen Planung und Konfigurierung unter dem Oberbegriff 
Konstruktion zusammen und zeigen Gemeinsamkeiten zwischen 
beiden Bereichen auf. Wir stellen unsere Ansätze zur Reprä- 
sentation von Konstruktionsobjekten vor. Dabei gehen wir von 
einer Begriffshierarchie aus, in der alle korrekten Kon- 
struktionen beschrieben sind. Die Begriffshierarchie dient 
dem Konstruktionsvorgang als Leitfaden. Der Konstruktions- 
vorgang endet, wenn eine nach der Begriffshierarchie 
zulässige und vollständige Konstruktion erzeugt wurde. 
Abschließend wird eine Blackboard-Architektur für ein 
System, das auf dieser Repräsentation arbeitet, skizziert. 



1. Einleitung 

Der vorliegende Artikel gibt einen Überblick über den bisherigen Stand unserer 
Arbeit, eine einheitliche Wissensrepräsentation und einen darauf operierenden 
Kontrollmechanismus für Planungs- und Konfigurierungsaufgaben zu entwickeln. 
Unser Ziel ist es, eine Exper tensystem-Entwicklungsumgebung zu schaffen, die 
speziell für Planungs- und Konfigurierungsaufgaben in technischen Anwendungen 
geeignet ist. 
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Die Entwicklung dieses Systems, genannt PLAKON, erfolgt im Rahmen des BMFT- 
Verbundpro jek tes TEX-K. Zur Validierung und zum Nachweis seiner Verwendbarkeit 
in heterogenen Anwendungen sollen mit PLAKON konkrete Expertensysteme für 
unterschiedliche Planungs- und Konfigurierungsaufgaben implementiert werden. 
Diese Anwendungsaufgaben sind: 

- Konfigurierung von Multi-Mikrocomputersystemen für Automatisierungs- 
systeme in der Anlagentechnik, 

- Konfigurierung von Bildverarbeitungssystemen für den industriellen 
Einsatz, 

- Konfigurierung automatischer Systeme der industriellen Röntgen- 
prüfung und der chemischen Analyse, 

- Planung mechanischer Bearbeitungs- und Fertigungsprozesse, z.B. 
Generierung von Arbeitsplänen in der mechanischen Teilefertigung. 

Ähnlich wie bereits existierende Shells, die vorwiegend für Diagnose- und 
Interpretationsaufgaben entwickelt worden sind (z.B. EMYCIN, HEARSAY III, MED2 ) , 
soll PLAKON den Aufbau von Expertensystemen unterstützen. Dazu werden unter 
anderem folgende Eigenschaften angestrebt: 

- Gleichermaßen für Planung und Konfigurierung geeigneter Ansatz. 

- Umfassende Repräsentationsmöglichkeiten für Konstruktionsobjekte 
(Geräte, Methoden, Operationen), durch die der Konstruktionsvorgang unter- 
stützt werden soll. 

- Flexible Ablaufsteuerung zur Realisierung typischer Konstruktions- 
strategien (interaktiv, hierarchisch, opportunistisch, Meta-Planung). 

Im Folgenden soll ein Ansatz beschrieben werden, mit dem sich die geforderten 
Eigenschaften erreichen lassen. 

2. Konstruktion — ein übergreifendes Konzept für Planung und Konfigurierung 
2.1. Konstruktion und Konstruktionsobjekte 

Planungs- und Konfigurierungsaufgaben unterscheiden sich von anderen Experten- 
system-Problemen wie z.B. Diagnose und Interpretation im Wesentlichen dadurch, 
daß aus vorgegebenen Einzelbausteinen eine Gesamtheit konstruiert wird, die 
bestimmten vorgegebenen Bedingungen, z.B. der Aufgabenstellung, genügt. Bei der 
Planung wird aus einzelnen Planschritten ein Gesamtplan aufgebaut, bei der 
Konfigurierung werden aus Einzelteilen Baugruppen gebildet. 
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Wir fassen Planung und Konfigurierung unter dem Begriff Kons truktionsvor gang 
zusammen, an dessen Ende als Ergebnis die fertige Konstrukt ion steht. Sie 
entspricht dem Plan bzw. der Konfiguration. Eine solche Konstruktion setzt sich 
aus Kons truktionsobjek ten (Planschritten bzw. Bauteilen) zusammen. Dies können 
Aggregate, d.h. zusammengesetzte Objekte, sein, die dann Grobplänen oder 
Baugruppen entsprechen. Demgegenüber bezeichnen wir die nicht weiter zerlegbaren 
Konstruktionsobjekte als Primitive. Dieser Aufbau ermöglicht ein hierarchisches 
Vorgehen bei der Konstruktion oder besser — mit [13] — eine Konstruktion 
auf Ebenen unterschiedlichen Details. Als Leitlinie für unseren Ansatz 
orientieren wir uns primär an der Konfigurierung und zeigen später, daß sich 
mit demselben Formalismus auch Planungsaufgaben ausdrücken lassen. 



Planung 




Konstrukt i onsvorgang 

erzeugt 


«« 


Konfigurierung 


Plan 




Konstruktion 

besteht aus 




Konfiguration 


Planschritte 


»» 


Konstrukti onsob j ekte 

können sein 




Bauteile 


Grobpläne 




Aggregate 




Baugruppen 


Einzelschritte 


»» 


Primitive 


«« 


Einzelteile 



Abb. 1: Begr if f szuordnung 



2.2. Die Begriffshierarchie 

Die Begriffshierarchie beschreibt konzeptionell die Konstruktionsobjekte und 
die Zusammenhänge zwischen ihnen. Sie repräsentiert somit die Menge aller mög- 
lichen Konstruktionen (vgl. [9]). Beim Konstruktionsvorgang orientiert 



sich die 



Ablaufsteuerung im Wesentlichen an der Begriffshierarchie. 
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Ein wichtiger Bestandteil der Begriffshierarchie ist die taxonomische Hier- 
archie . Sie ist ein Verband aus Objekten auf der Basis der is-a-Relat ion, 
der dazu dient, die Konstruktionsobjekte zu typisieren, Klassen von Objekten 
und deren Spezialisierungen (Unterklassen) zu beschreiben und Objekteigen- 
schaften festzulegen. Es werden die bekannten Techniken der Vererbung und der 
Def aultspezif ikat ion unterstützt. Der is-a-Verband enthält nicht die Objekte 
selbst, sondern nur deren Konzepte (oder Prototypen). Die Wurzel dieser 
Hierarchie ist dann das allgemeine Konzept Konstruktionsobjekt. 



Als weitere Unterstützung des Konstruktionsvorganges kann man verschiedene 
Sichten eines Objektes betrachten, die z.B. nur funktionale, elektrische 
oder räumliche Eigenschaften wiedergeben. Eine Objektsicht erhält man durch 
Ausblenden aller für sie nicht relevanten Eigenschaften. Jede Sicht definiert 
eine eigene Taxonomie. 



Zwischen den Objekten existieren für den Konstruktionsvorgang relevante 
Beziehungen, deren wichtigste die kompos i t ioneile ist. Sie wird mit Hilfe von 
par t-of -Kanten dargestellt und beschreibt die Zerlegung (Dekomposition) von 
Aggregaten in Teilaggregate und primitive Komponenten. Um mehrfaches Vorkommen 
von Komponenten in einem Aggregat ausdrücken zu können, wird mit diesen Kanten 
ein Anzahlfaktor assoziiert, der wahlweise eine Zahl oder, wenn die exakte 
Anzahl nicht bekannt ist, ein Intervall enthalten kann. (Diese Kanten kann man 
mit den value-restricted roles in semantischen Netzen vergleichen, wie sie in 
KL-ONE auf gebaut werden [3]). Außerdem ist es möglich, daß eine Komponente Teil 
mehrerer Aggregate ist, so daß wir zwischen exklusiven und mehrfach nutzbaren 
Komponenten unterscheiden müssen (im Beispiel (Abb. 2): Der Schrank in einer 
Schrankwand ist exklusiv dort eingebaut, der Stuhl in einer Schreibkombination 
könnte gleichzeitig auch in einer anderen Möbelgruppe genutzt werden). 

Konstruktionsrelevante Größen, die Eigenschaften eines einzelnen Objektes 
kennzeichnen, werden als Parameter bezeichnet und durch Slots in den die 
Objekte beschreibenden Frames repräsentiert (im Beispiel: Größe, Material und 
Position der Möbelstücke im Zimmer). Diese Slots sind in verschiedene Facetten 
unterteilt, die Informationen über Eigenschaftswerte, Wertrestriktionen, Wert- 
herkunft usw. enthalten. 
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Begriff shierarchie für eine Arbeitszimmer-Konfiguration 
mit par t-of -Kanten und zwei Nebenbedingungen. 



Zusätzlich können mit den Objekten Nebenbedingungen assoziiert werden, die die 
Wertzuweisung an die Parameter eines Objekts kontrollieren und die Zusammen- 
hänge zwischen Parametern beschreiben. Derartige Nebenbedingungen geben z.B. 
Minimal- und Maximalwerte für Parameterwerte oder funktionale oder symbolisch- 
regelhafte Beziehungen zwischen Parametern an. Nebenbedingungen, die sich auf 
mehrere Objekte beziehen, werden als Eigenschaften der sie umfassenden 
Aggregate dargestellt. Auch räumliche und zeitliche Beziehungen zwischen 
Objekten (z.B. als Abhängigkeiten zwischen Positionsparametern) können auf 
diese Weise ausgedrückt werden. 
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Die eigentliche Konstruktion, d.h. das Ergebnis eines konkreten Konstruktions- 
vorgangs, ist dann die Instanz i ierung eines Teilverbands der Begriffs- 
hierarchie. D.h., es werden Instanzen der Objekte erzeugt und gemäß der Vorgabe 
durch die kompositioneilen Beziehungen unter Festlegung freier Parameter und 
Berücksichtigung der angegebenen Nebenbedingungen zusammengefügt. Die 
Konstruktion wird durch eine aus den Ob jekt instanzen und part-of-Kanten 
bestehende Hierarchie beschrieben. Die im Verlauf des Konstruktionsvorganges 
entstehenden unvollständigen Zwischenzustände werden als 
Teilkonstrukt ionen bezeichnet. 

Die Teilkonstruktionen unterliegen nicht der Einschränkung, daß nur Instanzen 
von terminalen Konzepten auftreten dürfen. Dies steht im Gegensatz zu einer 
anderen Auffassung von Taxonomien, in der die Instanzen ausschließlich an 
terminale Knoten einer is-a-Hierarchie angebunden werden (vgl. LOOPS [2]). 
Nicht-terminale Instanzen müssen nachträglich spezialisiert werden, z.B. ein 
Möbelstück, von dem nur bekannt ist, daß es eine Art von Tisch ist, wird später 
zu einem Schreibtisch verfeinert (vgl. Abschnitt 3). 

2.3. Planung versus Konfigurierung 

Während wir uns bisher vorwiegend an der Konfigurierung orientiert haben, ist 
es jetzt notwendig, die zusätzlichen Anforderungen von Planung gegenüber 
Konfigurierung darzustellen. 

Bei der Konfigurierung kann man zwei Typen von Aufgaben unterscheiden: 
Komponentenauswahl und Parameter fest legung . Die Komponentenauswahl ist dadurch 
gekennzeichnet, daß ein komplexes System aus vielen Einzelteilen so zusammen- 
gesetzt werden muß, daß das fertige System und seine Teile gegebenen Spezifi- 
kationen genügen. Die Komplexität der Aufgabe ergibt sich in technischen 
Bereichen meist aus der großen Zahl der zu behandelnden Einzelteile und den 
schwer überschaubaren Abhängigkeiten zwischen diesen. Der andere Aufgabentyp 
ist die Einstellung der Parameter für gegebene oder konstruierte Komponenten 
so, daß alle Nebenbedingungen erfüllt sind. 

Bei der Planung stellt sich das Problem etwas anders dar: Zusätzlich zu den 

Konstruktionsobjekten eines Plans — den einzelnen Planschritten oder 
Operationen — werden weitere Objekte zur Beschreibung der Planungsumgebung 
benötigt. Es muß möglich sein, zeitlich veränderliche Zustände von Objekten 
auszudrücken. Die Komplexität der Aufgabe resultiert hier aus der Vielfalt der 
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Ano rd nu ng smog lichkei ten der Operatoren entlang der Planzeitachse der Schwierig- 
keit/ Abhängigkeiten zwischen Operatoren zu erkennen und optimal zu behandeln. 

Wir erweitern die Darstellungsmöglichkeiten um temporale Aspekte , mit denen 
der Zustand eines Objekts zu einem bestimmten Zeitpunkt beschrieben wird. Die 
Vorbedingungen und Wirkungen von Operationen werden durch Zustandsmuster 
beschrieben. Ein Plan wird dann in eine Folge von Operationen zerlegt» zwischen 
denen zusätzlich eine zeitliche Beziehung (nach Allen [1]) als Anordnungs- 
relation (vergleichbar einer räumlichen Anordnung der Komponenten im Arbeits- 
zimmerbeispiel) eingeführt wird. Für Operationen, deren Reihenfolge durch 
Vorgaben der Domäne festliegt, wird die Zeitrelation in der Begriffshierarchie 
verankert. Für die zeitliche Einordnung der Operationen entlang der Planzeit- 
achse wird die Übereinstimmung der Zustände durch spezielle Nebenbedingungen 
sichergestellt. Die temporalen Aspekte von Objekten, die während einer 
Operation unverändert bleiben, werden entlang der Zeitrelation propagiert, so 
daß die Wirkungen einer instanz i ier ten und zeitlich eingeordneten Operation 
immer die komplette Planumgebung beschreiben. 

Um nebenläufige Operationen und Mehr-Agent en-Pläne beschreiben zu können, wird 
die Dekomposition eines Plans derart organisiert, daß ein Plan aus mehreren 
Agent enplänen besteht. Ein Agentenplan enthält die von einem Agenten auszu- 
führenden Operationen. (Diese Agentenpläne ähneln den Zeitlinien, die T. Grant 
in [6] für die Ressourcenplanung einführt.) 

Die Unterteilung der Planungsproblematik (Begriffe nach [6]) in Präzedenz- 
planung und Scheduling (Ressourcenplanung) ist analog zu der oben getroffenen 
Unterscheidung von Konfigurierungsaufgaben zu sehen. Präzedenzplanung 
entspricht der Komponentenauswahl in dem Sinne, daß die zur Erreichung eines 
Ziels notwendigen Operationen bestimmt und geordnet werden müssen. Die 
zeitliche Anordnung erfolgt primär durch Erfüllung der entsprechenden Neben- 
bedingungen. Beim Scheduling sollen die Operationen, die bereits weitgehend 
bestimmt sind und in ihrer zeitlichen Reihenfolge teilweise geordnet sind, den 
Agenten und Ressourcen zugeordnet und konkret auf einer Zeitachse festgelegt 
werden. Operationsbeginn und -dauer werden als Parameter aufgefaßt. Man hat 
also wiederum eine Parameter fest legungsauf gäbe , die z.B. durch Propagierung der 
Nebenbedingungen gelöst werden kann. (Die so gewonnene Repräsentation von 
Plänen entspricht in Teilen der von M. Fox im System ISIS-2 [4) verwendeten.) 
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3. Konstrukt ions vor gang 

Nachdem wir den Repräsentationsformalismus vorgestellt haben, wenden wir 
uns dem eigentlichen Problemlösungsprozeß, dem Konstruktionsvorgang, zu. Ein 
Konstruktionsvorgang besteht aus einzelnen Konstruktionsschritten, durch die 
eine Teilkonstruktion in eine andere überführt wird. Dies bezeichnen wir als 
Elaboration . Alle Teilkonstruktionen werden explizit dargestellt und mit 
Elaborat ionskanten verbunden. Dieser sogenannte Elaborat ionsverband repräsen- 
tiert somit die gesamte Historie des Konstruktionsvorganges. Er kann damit als 
Grundlage für ein intelligentes Backtracking-Verfahren dienen. 

Die Teilkonstruktionen enthalten Instanzen von Konstruktionsobjekten und von 
par t-of-Kanten. Dabei sind nicht notwendigerweise alle Instanzen miteinander 
verbunden. Zu Beginn des Konstruktionsvorganges wird aus der Aufgabenstellung 
eine Anfangsteilkonstruktion bestimmt. Dann wird versucht, diese Konstruktion 
schrittweise in eine vollständige und korrekte Endkonstruktion zu überführen, 
in der dann entsprechend der Begriffshierarchie alle Instanzen gemäß ihrer 
par t-of-Bez iehung hierarchisch geordnet sind. 

Der Konstruktionsvorgang orientiert sich an der Begriffshierarchie. Sie 
unterstützt gleichermaßen ein Top-Down-Vorgehen (Verfeinerung von Aggregaten, 
Dekomposition) wie auch ein Bot tom-Up-Vorgehen (Aggregation von Komponenten). 
Dabei ergeben sich folgende elementare Konstruktionsschritte : 

1. Zerlegen ( Dekomponieren) von Objekten gemäß der part-of-Hierarchie 

durch Instanzi ieren mindestens einer Komponente. Als Beispiel: Ein 

Arbeitszimmer wird in seine Komponenten zerlegt, eine Schreib- 
kombination und 0..n weitere Z immer komponenten, wobei anfangs nur die 
Schreibkombination instanziiert wird. 

2. Spezialisieren von Objekten entlang der is-a-Kanten. Als Beispiel: 
Ein Tisch kann zu einem Sofatisch oder zu einem Schreibtisch speziali- 
siert werden. 

3. Aggregation von Teilkomponenten entlang der par t-of-Kanten, d.h. 
Instanz i ieren von Aggregaten. Wenn alle Teilkomponenten eines 
Konstruktionsobjektes vorhanden sind, kann man diese zusammenfassen. 
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4. Verschmelzen von einzelnen Objekten einer Teilkonstruktion. Hiermit 
können verschiedene Teile einer Teilkonstruktion ineinander überführt 
werden. Als Beispiel: Aufgrund der Aufgabenstellung muß ein Schrank im 
Arbeitszimmer vorhanden sein. Ein Arbeitszimmer besteht u.a. aus 0..n 
Zimmerkomponenten, und ein Schrank ist aufgrund der Begriffshierarchie 
ebenfalls eine Zimmerkomponente . Man kann nun den Schrank mit der 
Zimmerkomponente des Arbeitszimmers verschmelzen und ihn somit als 
part-of-Teil des Arbeitszimmers einsetzen. 

5. Parameterwerte fest legen oder einschränken. Dabei spielen die 

Nebenbedingungen eine wesentliche Rolle. Aufgrund unserer Anwendungs- 
gebiete benötigen wir an dieser Stelle auch die Möglichkeit zur 
Bewertung von Parametereinstellung, u.U. durch eine Simulation. 

Die Teilkonstruktionen werden jeweils daraufhin untersucht, welche Kon- 
struktionsschritte durchgeführt werden können. Diese werden dann als Eintrag in 
eine Agenda auf genommen. Gemäß einer frei programmierbaren Auswahlstrategie 
wird aus der Agenda jeweils ein Eintrag ausgewählt und der entsprechende 
Konstruktionsschritt durchgeführt. Diese Auswahl von Einträgen entspricht der 
Meta-Planung (vgl. [11]). 

Mit diesem flexiblen Ansatz hat man insbesondere die Möglichkeit, das opportu- 
nistische Planen von Hayes-Roth [7] nachzubilden. Beim opportunistischen 
Planen wird jeweils an derjenigen Stelle des Plans weitergearbeitet, die am 
günstigsten erscheint. Grundlage für eine Bewertung kann eine Analyse der 
Gesamtsituation des Problemlösungsprozesses oder der einzelnen Einträge sein. 
Die Anwendung einer opportunistischen Strategie ist dann sinnvoll, wenn es 
keine starre, von der Domäne vorgegebene Reihenfolge gibt, in der die Schritte 
bearbeitet werden sollen. 

Außerdem ist es möglich, die Auswahlstrategie auch dynamisch während eines 
Konstruktionsvorganges zu wechseln. Z.B. wurde bei MOLGEN [11] zuerst eine 
Least-Commi tment-St rategie eingesetzt, und später dann auf eine heuristische 
Strategie untgeschal tet . Dies kann realisiert werden, indem man zuerst nur 
Konstruktionsschritte auswählt, für die eine eindeutige Lösung existiert (least 
commitment). Erst wenn das nicht mehr möglich ist, findet eine Auswahl nach 
heuristischen Kriterien statt. 
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Weiterhin kann die Methode, mit der ein ausgewählter Konstruktionsschritt 
durchgeführt wird, variieren. Denkbare Methoden sind der Einsatz von Inferenz- 
regeln und Heuristiken, Benutzer interakt ion , Simulation u.a. 

Ein spezielles Verfahren zur Unterstützung des Konstruktionsvorganges ist die 
Verwendung von bereits in einer Bibliothek vorhandenen Lösung zu ähnlichen 
Aufgabenstellungen (vgl. [5], [10]). Diese Lösungen dienen dann als Leitfaden 

für die Auswahl und Durchführung von Konstruktionsschritten. Offen ist bislang 
noch, wie eine geeignete Lösung aus der Bibliothek ausgewählt werden kann. 

4. Ein Beispiel für Anwendungen dieser Konzepte 

Ein Beispiel für ein reales Konfigurierungssystem, das in der hier vorgestell- 
ten Weise Gebrauch von Begriffshierarchien macht, ist das BIKOS-System [12]. 
BIKOS dient zur Konfigurierung von Sichtprüfungsanlagen im Bereich der 
industriellen Qualitätskontrolle. Es hat die Aufgabe, ausgehend von der 
Spezifikation einer Prüfaufgabe, ein Bildverarbeitungssystem zu konfigurieren, 
das die notwendigen Sichtprüfungen ausführen kann. 

Die Konstruktionsobjekte von BIKOS sind Bildverarbeitungsgeräte, z.B. Kamera 
und Beleuchtungseinrichtungen, und Bildverarbeitungsmethoden, z.B. spezielle 
Segment ierungs- und Prüfverfahren. Abbildung 3 zeigt einen Teil des von BIKOS 
benutzten Methodengraphen. Der Methodengraph entspricht einem Auszug der oben 
entwickelten Begriffshierarchie. Es wird nur derjenige Teil der Hierarchie 
benutzt, der die konstruktionsrelevanten Entscheidungen steuert. Daher sind 
in BIKOS nicht alle im Methodengraphen verwendeten Objekte in eine Taxonomie 
eingebunden . 

Am BIKOS-System konnte anhand einer konkreten Anwendung gezeigt werden, daß 
diese Form der Wissensrepräsentation und -organisation viele Vorteile aufweist: 
- Durch die Strukturierung der Wissensbasis wird der Kontrollauf wand 
relativ kleingehalten. Insbesondere wird ein hierarchisches Vorgehen 
bei der Konstruktion unterstützt, d.h. das Bildverarbeitungssystem 
kann zuerst auf einer abstrakten Ebene entworfen und später verfeinert 
werden. Auftretende Konflikte können dabei vielfach schon früh erkannt 
und vermieden werden. 
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- Die Begriffshierarchie stellt die Vollständigkeit der Konfiguration 
sicher: Sie gibt vor, welche Komponenten zum Aufbau einer voll- 
ständigen Konfiguration notwendig sind. 

- Durch objektgebundenen Nebenbedingungen sind die gegenseitigen 
Abhängigkeiten in lokalen Bereichen der Hierarchie gebündelt, wodurch 
ein Backtracking in Grenzen gehalten werden kann. 



5, Die Grundstruktur von PLAKON 

Ausgehend von der Beschreibung des Konstruktionsvorgangs in Abschnitt 3 soll im 
Folgenden die vorgesehene Struktur des PLAKON-Kerns kurz skizziert werden. Wir 
orientieren uns dabei an der Black boar d-Ar chit ek tu r , wie sie in [8] vorge- 
schlagen wurde. Die wesentlichen Komponenten dieser Architektur sind das 
Blackboard, bestehend aus der dynamischen Wissensbasis und der Agenda, die 
Spezialisten (dedizierte Programmoduln) und der statischen Wissensbasis. 

Die Wissensbasis wird in zwei Bereiche unterteilt. Die statische Wissensbasis 
enthält die vollständige Begriffshierarchie, wie sie in Abschnitt 2 vorgestellt 
worden ist. Außerdem kann sie eine Bibliothek aufnehmen, die frühere Lösungen 
enthält. Die dynamische Wissensbasis enthält die Aufgabenstellung und den 
Elaborationsverband . 

Die auf dem Blackboard operierenden Spezialisten unterteilen wir in zwei 

Gruppen, die jeweils durch ihre Kontrollebene gekennzeichnet sind: 

- Ebene der Konstruktionsobjekte: Jedem Typ von Konstruktionsschritt 

(vgl. Abschnitt 3) entspricht ein Spezialist, der zwei Aufgaben hat: 

1. ) die vorhandenen Objekte in der Teilkonstruktion daraufhin 
zu überprüfen, ob er dort eingesetzt werden kann, und ggf. einen 
entsprechenden Eintrag in die Agenda vorzunehmen, und 

2. ) den Konstruktionsschritt auszuführen, sobald er dazu aufge- 

fordert wird. 

- Ebene der Meta-Planung: Dieser Spezialist wählt einen der Agenda- 

Einträge und damit einen Konstruktionsschritt aus. 

Der Konstruktionsvorgang läuft dann in einem dreistufigen Zyklus ab, der aus 
den Schritten 

- Erkennen der durchführbaren Konstruktionsschritte, 



- Auswahl eines Schrittes und 
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- Durchführung dieses Schrittes 
besteht . 

Vervollständigt wird die Grundstruktur durch eine Benutzerschnittstelle, eine 
Wissensakquisit ions- und eine Erklärungskomponente. Es ist vorgesehen, 
Benutzer interaktion auf jeder Entscheidungsebene zu ermöglichen. D.h. der 
Benutzer kann an jeder Stelle den jeweiligen Spezialisten ersetzen. 




Grundstruktur für die PLAKQN-Archi tektur 



Speztöftsten für 
konst r -Objekte 
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6 . Zusammenfassung 

Unsere Untersuchungen haben ergeben, daß ein gemeinsamer Ansatz für Planungs- 
und Konfigurierungsaufgaben sinnvoll und möglich ist. Wir haben einen Wissens- 
repräsentationsformalismus entwickelt, der den Konstruktionsvorgang dadurch 
unterstützen und leiten soll, daß die möglichen Entscheidungen deklarativ 
vorgeprägt sind. Am BIKOS-System hat sich gezeigt, daß der gewählte Ansatz 
viele Vorteile aufweist. 

Zur Zeit beschäftigen wir uns mit einer prototypischen Implementierung des hier 
vorgestellten PLAKON-Kerns unter Verwendung von Knowledge Craft. Weitere 
Schwerpunkte sind der Entwurf eines geeigneten Constraint-Mechanismus und die 
Vertiefung des Sichtenkonzeptes. 
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EXIST - ein Expertensystem zur innerbetrieblichen 
Standortplanung 



Zusammenfassung 

Im folgenden wird die Entwicklung von EXIST, der Prototyp eines wis- 
sensbasierten Systems zur Fabriklayoutplanunug, beschrieben. Um 
qualitativ hinreichende Lösungen zu erhalten, wird das Expertenwis- 
sen, im Gegensatz zu algorithmischen Verfahren herkömmlicher Struk- 
tur, durch geeignete Repräsentationen adäquat dargestellt und verar- 
beitet. Hybride Expertensystem-Tools wie Babylon und eine Weiterent- 
wicklung Babylon+ verringern aufgrund der Integration verschiedener 
Inferenzmechanismen und Wissensrepräsentationen den Aufwand für 
die Entwicklung eines Expertensystems. Ein bei Design-Systemen oft- 
mals verwendetes Architektur-Prinzip, der Blackboard-Architektur, 
ist auch für diese Problemstellung konzipiert worden. Die für diese 
Architektur typische Trennung des Wissens in qualitatives und quanti- 
tatives Expertenwissen, sowie die Möglichkeit, konkurrierende Ziele 
zu verarbeiten, eignen sich besonders für die Anwendung in der 
Layoutplanung. 



Schlüsselwörter 



Planung und Entwurf, Wissensrepräsentation 
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1. Einleitung 

1.1 Problemdarstelluna 

Bei der innerbetrieblichen Standortplanung geht es um eine unter 
gegebenen Zielen und Restriktionen optimale Zuordnung von Betriebs- 
mitteln (im allgemeinen handelt es sich hierbei um Maschinen) auf 
einer Basisfläche [13]. 

Die Notwendigkeit einer neuen Standortplanung kann aus verschiedenen 
Gründen gegeben sein. Bei der Erweiterung oder Umstrukturierung 
bestehender Anlagen steht die Effizienzanalyse des existierenden 
Layouts am Anfang. Anschließend findet eine Verträglichkeitsuntersu- 
chung mit den gesteckten Zielen statt. Bei der Produktionserweiterung 
könnte es sich um eine optimale Anlagerung neuer Maschinen handeln. 
Bauliche Gegebenheiten sowie eine feste Anordnung der Betriebsmittel 
fließen bei dieser Problemstellung als Restriktionen mit ein. Neuin- 
stallierungen oder Neuplanungen enthalten in der Regel nicht so viele 
starke Restriktionen. Dafür ergeben sich bei den Anordnungen der 
Betriebsmittel vielfältigere Möglichkeiten [11, 19]. 

Das hinter der Layoutplanung stehende Zuordnungsproblem oder Koop- 
manns/Beckmann-Problem spielt in der mathematischen Optimierung 
und ihren Anwendungen eine bedeutende Rolle. Obwohl seit den 50er 
Jahren intensiv auf diesem Gebiet gearbeitet wird, konnte mit den 
Lösungsansätzen in der Fabriklayoutplanung noch kein entscheidender 
Durchbruch erzielt werden [9]. 

Konventionelle computergestützte Layoutplanungsverfahren zeichnen 
sich durch eine eingeschränkte Lösungsqualität aus. Wissensbasierte 
Verfahren erlauben dagegen in einigen Bereichen die Annahme, daß 
diese Techniken gegenüber herkömmlicher Datenverarbeitung qualita- 
tiv bessere Problemlösungen erstellt. Daß diese Prognose auch für das 
Gebiet der innerbetrieblichen Standortplanung gilt, wird im folgenden 
begründet. 



1. 2 Warum ist der Einsatz eines Expertensvstems sinnvoll? 

Gründe für den Einsatz eines Expertensystems in der innerbetrieb- 
lichen Standortplanung lassen sich bei der Charakterisierung der Pro- 
bleme erkennen, die zu den eingeschränkten Einsatzmöglichkeiten der 
existierenden konventionellen Programme führen. Die meisten beste- 
henden algorithmischen Verfahren arbeiten unter einfacher Zielset- 
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zung, das heißt sie optimieren lediglich den Materialfluß und ignorie- 
ren dabei sämtliche anderen Einflüsse, die ein menschlicher Planer 
noch berücksichtigt. Der Layoutexperte beachtet bei der Zuordnung 
auch noch die diversen Transportmittel, die optimalen Fertigungsty- 
pen, Sympathie- und Antipathiebeziehungen zwischen den Betriebs- 
mitteln, auftretende Kosten und viele Gesichtspunkte mehr, denen oft- 
mals nur seine eigenen Erfahrungswerte zugrunde liegen. Es existieren 
zwar mittlerweile auch schon neuere Programme, die sich mit algo- 
rithmischen Mitteln auf diesem Gebiet versuchen. Sie kommen aber 
nicht über einen rudimentären Ansatz hinaus [4, 18]. 

Die Komplexität und einseitige Behandlung des Problems kann durch 
Benutzung zusätzlicher Kriterien umgangen werden. Da diese sich oft- 
mals aus unsicheren Daten und Erfahrungswerten eines Planers erge- 
ben, bietet sich an dieser Stelle der Einsatz eines Expertensystems an. 
Ein weiterer wesentlicher Vorteil eines Expertensystems ist die Ver- 
arbeitung verschiedener, teilweise konkurrierender Zielsetzungen, so 
daß mit einem wissensbasierten System eine Optimierung unter mehr- 
facher Zielsetzung möglich ist. Das Problem der simultanen Betrach- 
tung mehrerer verschiedener Ziele wurde bis jetzt von keinem Pro- 
gramm gelöst. 

Aufgrund des Abstraktionsniveaus erlauben bisherige Programme zwar 
teilweise eine universelle Anwendung auf die innerbetriebliche Stand- 
ortplanung, verzichten aber auf Praxisnähe, da ohne Berücksichtigung 
der speziellen Art der Anlage wichtige Randbedingungen und Restrik- 
tionen wegfallen. Diese Einflüsse und Bedingungen, die in der Regel aus 
Heuristiken und vagen Daten bestehen, sind wichtiger Bestandteil der 
Wissensbasis eines Expertensystems, was diesem ermöglicht, ein rea- 
listisches Layout zu entwerfen. Somit ergäbe sich für ein von einem 
Expertensystem erstelltes Fabrik layout eine direkte Anwendungsmög- 
lichkeit, während bei den Layouts, die aus konventionellen, algorith- 
mischen Verfahren entstanden, eine Modifizierung durch den Planer 
nötig ist, die in der Regel eine Reduzierung der Optimalität zur Folge 
hat [20]. 

2. Benutzte Techniken 

2.1 Babylon 

Hybride Werkzeuge, die verschiedene Wissensrepräsentationsformen 
und Inferenzmechanismen integriert zur Verfügung stellen, beschleu- 
nigen die Programmentwicklung und verbessern die Effizienz eines 
Expertensystems. Die Idee solcher Systeme liegt in dem Versuch, 
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durch die Integration heterogener Wissensrepräsentationen das Wissen 
in seiner natürlichsten Form adäquat darstellbar zu machen. Für die 
Entwicklung von EXIST stand die Betatest-Version von Babylon zur 
Verfügung [10]. 

Babylon stellt mit einer objektorientierten, einer regelorientierten 
und einer logikorientierten Repräsentation drei Wissensrepräsentatio- 
nen zur Verfügung, die alle von einem eigenen Basisprozessor abgear- 
beitet werden. Die Koordination der Basisprozessoren und die interak- 
tive Schnittstelle mit dem Benutzer steuert ein Metaprozessor. Mit 
Hilfe dieser Maßnahme ist versucht worden, dem Prinzip des verteil- 
ten Problemlösens gerecht zu werden [7]. 

Im folgenden werden Unzulänglichkeiten, mit denen die verwendete 
Betatest-Version von Babylon noch behaftet ist, kurz erläutert. 

Schon bei den ersten Handhabungsversuchen mit Babylon stellt sich als 
Manko ein Mangel an Informationen über den Babylon-Systemzustand 
heraus. Es ist in Babylon nicht möglich, etwas über die Konstellation 
des erstellten Expertensystems zu erfahren. Die Schwächen, die bei 
statischen Anwendungen wie Diagnosesystemen mit festem Konfigu- 
rationsraum und damit konstanter Anzahl von Instanzen nicht ins 
Gewicht fallen, machen sich bei dynamischen Anwendungen (und dyna- 
misch erzeugten Objekten) bemerkbar. Es fehlt die Möglichkeit, 
Objekte zu erzeugen und zu löschen und diese temporäre Instanzen zu 
verwalten. Ein analoges Problem ergibt sich daraus bei der regelorien- 
tierten Repräsentationsform, die keine Variablen oder Parameter bei 
den Regeln und Regelpaketen zuläßt, und damit die Verarbeitung dyna- 
mischer Objekte ausschließt. 



Bei Design-Systemen im allgemeinen und bei EXIST im speziellen ist 
aufgrund der unterschiedlichen Problemstellung der verschiedenen 
Anwendungen eine dynamische Verarbeitung unerläßlich. In der End- 
version Babylons sollen die oben aufgeführten Mängel beseitigt sein; 
da diese Version zu diesem Zeitpunkt aber noch nicht zur Vefügung 
stand, erschien es sinnvoll, EXIST nicht in der Beta-Test-Version von 
Babylon, sondern in Babylon+ [5, 6], einer internen Weiterentwicklung 
auf der Basis von Babylon, zu implementieren. 



2. 2 Babylon* 

Die grundlegende Idee bei dem Entwurf von Babylon+ ist die Implemen- 
tierung der neuen Konzepte mit Hilfe der erweiterten Babylon- 
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Konstrukte. Ein einheitlicher Aufbau der verschiedenen Bausteine, 
dynamische Verwaltung und Zugänglichkeit des Systemzustandes sind 
als vorrangige Ziele zu nennen. Außerdem zeigte sich nach den ersten 
Anwendungen die Notwendigkeit einer flexibleren Handhabung der 
regelorientierten Repräsentation. Letztere ist in einer Erweiterung 
der Regelmengen um Variablen und Parameter realisiert. Ein Klassen- 
konzept, das dem in Smalltalk [12] verwendeten ähnlich ist, dient als 
Grundlage der anderen verwendeten Konstrukte und ermöglicht somit 
eine objektorientierte Repräsentation, die nicht mit den Einschränkun- 
gen der Babylon-Frames behaftet ist. 

Ein wesentlicher Vorteil des Klassenkonzeptes in Babylon+ ist die 
Eröffnung zusätzlicher Eigenschaften und Möglichkeiten der in Babylon 
passiven Frames als aktive Einheiten (Klassen) in Babylon+. Im Gegen- 
satz zu den Frames in Babylon, deren Slots und Methoden nur über 
Instanzen zugreifbar sind, verfügen die Klassen in Babylon+ noch über 
eigene Slots und Klassenmethoden, die von den Klassen selbst 
ansprechbar sind. Dies erleichtert sowohl die Verwaltung als auch den 
interaktiven Umgang mit den Klassen, deren Methoden und Instanzen. 

3. Entwurfs- und Implementationstechniken 

2J Desian-Svsteme 

Aufgrund der Problemstellung bei der innerbetrieblichen Layoutpla- 
nung ist die Charakterisierung eines Expertensystems für diese Aufga- 
benstellung als Design-System zulässig. Analoge Anwendungen erge- 
ben sich zum Beispiel bei VLSI-Design-Systemen wie WEAVER [16] und 
MICON [8] oder anderen Anwendungen wie ROUTE-FINDER [17], deren 
Konzepte und Entwürfe hier ausschnittsweise behandelt werden. 

Bei dem Versuch, die Struktur und Charakteristika der zu behandelnden 
Objekte zu formalisieren, ergibt sich bei allen Systemen das Problem 
der räumlichen Repräsentation der Objekte und der räumlichen Argu- 
mentation mit diesen. Vorzugsweise ist das Wissen über die Objekte 
in metrische Fakten einerseits und topologische Fakten andererseits 
unterteilt. Somit wird eine Trennung zwischen quantitativer Verar- 
beitung des metrischen Wissens und qualitativer Argumentation über 
die topologischen Beziehungen der Objekte erreicht. 

Allen Systemen gemeinsam ist der Versuch, im Planungsprozeß die 
Aufgaben und Ziele in Teilaufgaben und Unterziele zu unterteilen und 
ausführen zu lassen. Die Planung wird somit als eine Methode gesehen, 
den Suchraum des Expertensystems durch gezielte Führung des Pro- 




426 



blemlösungsprozesses in Unterprobleme zu reduzieren. Da die Unter- 
probleme nicht unabhängig voneinander sind, wirkt sich eine isolierte 
Untersuchung dieser Teilaufgaben im allgemeinen negativ auf die 
Qualität der Endlösung aus [16], Um dieser Abhängigkeit gerecht zu 
werden, sind die Architekturen der Systeme durch ein Task-Network 
[17] oder als Blackboard-Architektur [8, 16] realisiert. 

Die drei wesentlichen Merkmale einer Blackboard-Architektur sind die 
Wissensquellen, die unabhängig voneinander Einträge in eine globale, 
strukturierte Datenbasis, das Blackboard, ausführen, sowie ein intel- 
ligenter Kontrollmechanismus, der die Steuerung der unterschied- 
lichen Wissensquellen übernimmt [14]. 
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Abbildung 1 : Blackboard-Architektur 



Insbesondere diese Blackboard-Architektur eignet sich in hervorra- 
gender Weise für die Anforderungen eines Design-Systems. Die Vor- 
teile liegen vor allen Dingen in der Integrationsmöglichkeit multipler 
Wissensquellen und verschiedener Problemlösungskomponenten. Die 
Möglichkeit, heuristische Methoden für die Auswahl dieser Quellen und 
Komponenten einzusetzen, sowie konkurrierende Ziele quasi-parallel 
zu verarbeiten, sind vergleichbar mit menschlicher Vorgehensweise 
bei der Problemlösung. Außerdem ist die Kontrolle durch den Benutzer 
mittels Interrupts einfach zu realisieren [15]. 
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3. 2 EXIST-Obiektbeschreibunq 

Die von EXIST verarbeiteten Komponenten des Layouts sind in einer 
Klassenhierarchie abgebildet, um so den verwandten Eigenschaften der 
Objekte gerecht zu werden. Mit Hilfe der Vererbungsmöglichkeiten der 
Klassenhierarchie lassen sich direkt und einfach die speziellen und 
gemeinsamen Charakteristika der zu behandelnden Objekte beschrei- 
ben. 




Abbildung 2: Klassenhierarchie der Objekte in EXIST 



Die Klasse Fläche ist Superklasse aller weiteren genannten Klassen 
und enthält insbesondere die Beschreibung der metrischen Fakten und 
Eigenschaften eines Objektes. Eine Instanz der Klasse Basisfläche 
stellt den Standortträger dar, auf dem die Zuordnung realisiert wird. 
Sie unterscheidet sich somit von den restlichen Objekten, die alle auf 
dieser Basisfläche positioniert werden. Als Superklasse für 
zuzuordnende Objekte enthält die Klasse Plan-Fläche vor allen Dingen 
die Verwaltung der Nachbarschaftsbeziehungen zwischen den positio- 
nierten Flächen und deren relativer Lage zueinander. Die Klasse 
Sperrfläche beschreibt Flächen auf der Basisfläche, die für die Anla- 
gerung der Betriebsmittel nicht zugänglich sind (z. B. Stützkonstruk- 
tionen, Treppenhäuser oder Böden mit zu geringer Tragfähigkeit). 
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Sämtliche Objekte, die in dem Layout als Transportwege benutzt wer- 
den, sind Instanzen der Klasse Weg. 

Vorrangiges Ziel der Anwendung ist die optimale Zuordnung der 
Betriebsmittel, die in qualitativer und quantitativer Beziehung zuein- 
ander stehen. Diese Abhängigkeiten ergeben sich aus dem Materialfluß 
oder den Sympathie- und Antipathiebeziehungen, die durch einen 
Zugriff auf gleiche Ressourcen oder eine gegenseitige negative Beein- 
flussung hervorgerufen werden. 

Die einzelnen Ausprägungen der Betriebsmittel lassen sich hinsicht- 
lich ihrer Restriktion bezüglich der Positionswahl unterscheiden in 
Objekte mit fester Position (Fixfläche), Objekte mit eingeschränkter 
Positionswahl (Festfläche, das heißt Flächen, die in einem bestimm- 
ten Bereich angeordnet werden müssen) und Objekte ohne Lage- 
Restriktionen (Freie-Betriebsmittel). 

3. 3 Flächenbeziehunaen 

Ein wichtiges Problem bei der computergestützten Layoutplanung ist 
die Darstellung der zu behandelnden Objekte und damit auch die Reprä- 
sentation der Positionierung der Flächen auf eine Basisfläche. Die 
Rasterung in herkömmlichen Verfahren, die die Basisfläche und sämt- 
liche anderen Flächen aus Rastereinheiten zusammensetzen, bringt den 
Nachteil einer unpräzisen Darstellung mit sich und impliziert einen 
großen Aufwand bei der Zusammensetzung der Freiräume. 

In EXIST können die Objekte beliebige Maße erhalten und ihre Position 
auf der Basisfläche sind mit Hilfe von Koordinaten bestimmt. Die 
objektorientierte Repräsentation erlaubt es, auf die komplizierte 
Generierung von Freiräumen zu verzichten und jedem Objekt das Wis- 
sen über seine individuelle Umgebung zuzuordnen. 

Um das Wissen über diese Umgebung eines Objektes beschreiben zu 
können, ist eine formale Repräsentation der Nachbarschaftsbeziehun- 
gen und der relativen Lagen der Flächen untereinander notwendig. Die 
Verarbeitung dieser Nachbarschaftsbeziehungen ist ein wesentliches 
Merkmal des Zuordnungsproblems von Betriebsmitteln auf einer 
Basisfläche. Eine Darstellung der Beziehungen als Relationen entstand 
aus einer Theorie über die Zeitbeziehungen von James F. Allan [1 , 2, 3]. 
Die Relationen, die Allan für das eindimensionale Problem der 
Zeitbeziehungen aufgestellt hat, lassen sich auf die zweidimensionale 
Anwendung der Flächenbeziehungen übertragen. Der Ausschluß 
bestimmter Beziehungen aufgrund der Problemstellung (z.B. ist in der 
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Layoutplanung keine Überlappung von Flächen vorgesehen) ermöglicht 
die Zusammenfassung verschiedener Beziehungen zu Nachbarschafts- 
bereichen, für deren Beschreibung lediglich vier Relationen benötigt 
werden. 

Zunächst ist es notwendig, die Fläche eines Objektes auf einen 
Bezugspunkt in der Basisfläche zu reduzieren, um den Ursprung für ein 
orthogonal geteiltes Feld mit vier Nachbarschaftsbereichen zu schaf- 
fen. Dieser Bezugspunkt ist die linke untere Ecke einer Fläche, also der 
Flächenpunkt mit den kleinsten x- und y-Koordinaten. 
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Abbildung 3: Nachbarschaftsrelationen 
Für die Relationen gelten nun folgende Beziehungen: 

1 . Fläche A (hat Nachbarn) Obenrechts B <=> (X A < X B ) und (Y A < Y B ) 

2. A untenrechts B <=> (X A < X B ) und (Y A > Y B ) 

3. A untenlinks B <=> (X A > X B ) und (Y A > Y B ) 

4. Aobenlinks B <=> (X A > X B ) und (Y A < Y B ) 

Folgende Relationen sind invers zueinander: 

A obenrechts B <=> B untenlinks A 
A obenlinks B <=> B untenrechts A 

Außerdem sind alle Relationen transitiv, es gilt also für Rel aus 
{obenrechts, obenlinks, untenrechts, untenlinks}: 

A Rel B und B Rel C => A Rel C 

Dieses Verhalten verringert erheblich den Aufwand bei der Verwaltung 
der Nachbarschaftsbeziehungen, da nun für eine Fläche lediglich die 
direkten Nachbarn von Interesse sind. 
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Aufgrund der geschilderten Relationen Kennt nun jede positionierte 
Fläche ihr Umfeld und ihre direkten Nachbarn. Dieser Tatbestand ist 
ein wesentlicher Bestandteil der auf dem Blackboard liegenden Struk- 
tur und erleichtert die Analyse der bestehenden Layoutkonfiguration. 

3. 4 EXIST-Blackboard-Architektur 

Wie sich die in 3.1 aufgeführten Erkenntnisse in der Struktur der 
EXIST-Architektur niederlegen, zeigt eine schematische Darstellung in 
Abbildung 4. 




Abbildung 4: Architektur von EXIST 

Das Blackboard enthält die Darstellung der zu behandelnden Objekte 
und somit die Verwaltung der Nachbarschaftsbeziehungen einschließ- 
lich der Verarbeitung der Relationen. Zusätzlich existieren noch Pla- 
nungshilfsmittel, wie eine Materialflußmatrix und eine Transportmit- 
telmatrix, die ein Planer zur Unterstützung seiner Planungsentschei- 
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dung benutzt. Damit ist auf dem Blackboard die gesamte Konstellation 
der aktuellen Problemstellung beschrieben. 

Die Klasse Focus-of-attention repräsentiert den wissensbasierten 
Kontrollmechanismus, der aufgrund einer Analyse der Layoutkonfigu- 
ration und der Blackboard-Struktur eine Komponente auswählt und 
aktiviert. Für die Analyse werden Regelpakete verwendet, um den Vor- 
teil einer leichten Änderbarkeit und Erweiterbarkeit durch Hinzufügen 
neuer Regeln zu nutzen und einer datengetriebenen Selektion der 
Wissensquellen gerecht zu werden. Außerdem steht, über die Regeln in 
Babylon, dem Benutzer in eingeschränktem Maße eine Erklärungskom- 
ponente zur Verfügung, die das Verständnis über den Problemlösungs- 
weg erweitert. 

Die einzelnen Wissensquellen repräsentieren die unterschiedlichen, 
teilweise sich konkurrierenden Zielsetzungen und arbeiten die ver- 
schiedenen Unterprobleme der Gesamtaufgabenstellung ab. Die Verar- 
beitung der Abhängigkeiten dieser Wissensquellen geschieht integriert 
mit der Analyse des Blackboards in der Klasse Focus-of-attention. Die 
Selektion einer Wissensquelle ist somit von der aktuellen Konstella- 
tion des Layouts abhängig. So existieren zum Beispiel Transportmittel, 
die eine Gruppierung von Betriebsmitteln erforderlich machen, und 
somit die Umsetzung bereits positionierter Betriebsmittel und die 
Erzeugung eines zusätzlichen Weges nach sich ziehen. Die Auswahl des 
Optimierungskriteriums ist abhängig von den Beziehungen der noch zu 
positionierenden Flächen, so daß nach jeder Anlagerung überprüft 
werden muß, ob ein Kriterium geändert werden soll oder nicht. 

Neben den Komponenten, die für die verschiedenen Unterprobleme 
installiert sind , existiert noch die Möglichkeit für den Planer, indivi- 
duelle Planungsmaßnahmen über ein Interaktions-Konzept einzubinden. 

4. Ausblick 

Bei der in Abbildung 2 dargestellten Objekthierarchie sind bis auf die 
Wege und Festflächen sämtliche Klassen mit ihren Eigenschaften 
implementiert. Insbesondere existieren die für die Anlagerung von 
Planflächen wichtigen Nachbarschaftsrelationen und Methoden zur 
Positionierung, die auch auf die fehlenden Klassen ohne Einschränkun- 
gen anwendbar sind. 

Außerdem fehlen noch einige Komponenten der in Abbildung 4 aufge- 
führten Architektur, da es sinnvoll erschien, zunächst einige Klassen 
vollständig zu implementieren, um ihre Anwendbarkeit zu testen. 
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Schließlich beschränkt sich die Auswahl der Optimierungskriterien 
bisher auf den Materialfluß und Sympathie- bzw. Antipathiebeziehun- 
gen zwischen Betriebsmitteln und Basisfläche einerseits und zwi- 
schen verschiedenen Betriebsmitteln andererseits. 

Bei der Weiterentwicklung der EXIST-Architektur sind wichtige 
Erkenntnisse über den sinnvollen Einsatz einer Blackboard-Architektur 
in einem Design-System zu erwarten. Erste ermutigende Resultate 
zeigen, daß das Expertenwissen auf diese Art adäquat dargestellt und 
verarbeitet wird. Vor allen Dingen lassen die Einbindung des Wissens 
über optimale Transportmittel und eine größere Zahl verschiedener 
Optimierungskriterien noch eine Steigerung der Lösungsqualität 
erwarten. Die Berücksichtigung der unterschiedlichen Transportmittel 
setzt allerdings die Existenz eines Wegenetzes voraus und impliziert 
damit die Implementation der Klassen Focus-Weg und Weg (vgl Abb. 2 
und 4). 

Die Eingangs gestellte Frage, ob sich ein Expertensystem für die 
innerbetriebliche Standortplanung lohnt, kann aufgrund der ersten 
Erfahrungen grundsätzlich positiv beantwortet werden. 

Es zeigt sich, daß sich das Wissen eines Experten geeignet formalisie- 
ren läßt. Insbesondere die Verarbeitung konkurrierender Ziele erweist 
sich als realitätsnah und vergleichbar mit menschlicher Vorgehens- 
weise. Die Zahl der Restriktionen und Ziele, die das System verarbei- 
ten kann, sowie die Möglichkeit der Erweiterbarkeit der Wissensbasis 
durch einfache Eingabe neuer Regeln im Diagnoseteil (Focus-of- 
attention) bieten eine universelle Anwendung bei gleichzeitig rea- 
listischer Lösung. 

Erste Anwendungsversuche mit Planern zeigen, daß zudem die Interak- 
tivität und damit die Einbindung des Planers in den Planungsprozeß 
des Systems zu einem konstruktiven Ergebnis führen. 
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Abstract: PEPS is an expert system for the modeling and 
simulation of technical processes, whose knowledge has the fea- 
tures that it is gained mainly by experiments, consists out of 
both, quantitative and qualitative data, and depends often on 
estimations of experts. This is demonstrated by means of the 
automatic welding process. For the representation of this kind 
of knowledge, in the system PEPS quasi-quantitative values and 
plausibility estimations are used. Processes are defined by 
their parameters and rule sets assigned to them and by influen- 
ces between the parameters. Elementary processes can be aggre- 
gated to larger ones. 



1 Introduction 



For about 8 or 1 0 years, efforts were made by several 
researchers to develop new devices in order to represent and 
reason upon technical systems and processes in the framework of 
expert systems. These researchers felt, that the MYCIN-techni- 
ques for knowledge representation and processing were too weak 
to be applied to dynamic systems, e.g. technical systems. The 
new field of research that was opened up to overcome the short- 
comings of the MYCIN approach is called "qualitative reasoning" 
There are two main directions of research in this field, the 
component oriented description and the process oriented descrip 
tion of technical systems. In the first one, established by de 
Kleer [4], a technical system is conceived as composed of a 
number of elements, the components, and it is assumed that the 
behavior of the whole system can be derived from that of the 
components with regard to their composition. In the second one, 
established by Hayes and Forbus [5,6,7], processes, conceived 
as entities that change parameter values and even the topology 
of a technical system, are the basic elements of description. 
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The component oriented approach seemed to be the more 
attractive one, because a number of researchers tried to apply 
it, mainly to circuit design and diagnosis [2,3,11,12], and only 
little work was done in the lines of the process oriented ap- 
proach. In industrial production however, there is a lot of 
things going on that can't be adequately described as the beha- 
vior of a system composed of components, rather the concept of 
the process is more appropriate. We have choosen such a part of 
a production process, namely automatic welding, and modeles it, 
following the principles of qualitative reasoning. However, when 
examining the available material and inquiring an expert, it 
turned out that Forbus' process definition was not helpful for 
us as it stands. This is due to tha rather vague and fragmentary 
knowledge that is available about automatic welding. Therefore 
we had to pay attention to the problems arising from this fact. 

In the second section of this paper, automatic welding 
is described along with the requirements of the welding experts 
to an expert system for the simulation of this process, and the 
special features of the description of the welding process in 
the literature are recorded. These features seem to be typical 
for a whole class of processes, of which automatic welding is an 
instance, and they are therefore reformulated on a more general 
level in section 3. In section 4, the way of qualitative reaso- 
ning in the system PEPS is described. Finally, section 5 gives 
the definition of processes and aggregations of processes. 

2 The automatic welding process 

The usual method of automatic welding is the GMA welding, 
shown in figure 1. There, an arc. is inflamed between two elec- 
trodes if the voltage is high enough. One of the electrodes is 
a melting electrode that is pushed forward out of the welding 
torch with constant speed, the other is the workpiece. The arc 
melts the top of the wire and some region on the workpiece and 
transports melted material from the wire to the workpiece. A 
special gas shielding is used to prevent the melted metal from 
oxidation. It can consist of carbon dioxyde or a mixture con- 
taining argon. 




w r r*£ 








Figur« 2: Two welding seam profiles, one V-shaped with wide rim {top) 
and one U-shaped (bottom). 
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The result of the welding process is a welding seam on 
the workpiece, which may have different profiles, e.g. those 
shown in figure 2, and different qualities, depending on a num- 
ber of parameters that can be manipulated by the welding expert. 
These parameters are the composition of the gas shielding, dia- 
meter of the wire, speed of the wire, voltage, torch distance, 
torch position in relation to the workpiece, thickness of the 
workpiece, form and width of the gap between the two parts of 
the workpiece that are welded together, welding position (e.g. 
upward, downward) , and welding speed. 

The information about the influences of the adjustable 
parameters on the resulting parameters (concerning the welding 
seam) is partly encoded in "welding data tables" and partly in 
rules. An entry in a welding data table is an n-tuple of values, 
one for each of the adjustable and resulting parameters. Thus, 
a welding data table can be conceived as a partial mapping from 
the adjustable to the resulting parameters. However, the domain 
of this mapping consists only of a finite set of single points 
in the m-dimensional space of adjustable parameters, and the 
gaps between these points are more or less large 

The rules, on the other side, are given verbally and are 
qualitative in nature, because in general they don't relate 
exact values of parameters. Some examples of rules are: 

"The melting-off efficiency is proportional to the wire 
diameter and the wire speed." 

"The welding seam volume is inverse to the wire speed." 

"If the gas shielding is rich of argon and the welding 
speed is higher than 40 cm/min, then the welding seam has a U- 
shaped profile." 

All these informations, the rules as well as the welding 
data tables, are achieved by experiments, and can be found in 

[1,8,9]. 

Obviously, these kinds of knowledge sources cause some 
problems. How to use the welding data tables which give only 
sparse information? How to deal with the qualitative information 
of the rules? How to integrate quantitative and qualitative in- 
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formation in the welding data tables and rules respectively? 
However, things get even more complicated. It is impossible to 
give a closed physical model of the welding process, because the 
knowledge about it is rather fragmentary. The influences of ad- 
justable parameters on resulting parameters can be hardly quan- 
tified. The experts know that the adjustable parameters have 
different influence rates on the resulting parameters, but they 
can only estimate these rates according to practical experience, 
and, as is pointed out in [10], different experts give different 
estimations. 

What the welding experts originally expected from a sy- 
stem modeling the automatic welding process, was the computation 
of optimal values of the adjustable parameters, starting from a 
particular result, i.e. welding seam. However, when inspecting 
the material, it turned out that this was impossible with the 
available information, because it is too fragmentary. Instead, 
the system PEPS that has been implemented, is a tool by which 
the expert may experiment in order to refine and increase the 
knowledge at hand. This is explained in section 4 in more de- 
tail. 

3 Processes described by experimental knowledge 

It is hard to believe that the welding process is the 
only process with the features described in section 2. Rather, 
it can be assumed that it is just an instance of a class of pro- 
cesses of the same type. Abstracting from the observations we 
made within the welding process, the main features of this pro- 
cess class can be described as follows. 

Experimental knowledge. 

The bulk of the knowledge about a process is achieved by 
experiments, basic physical knowledge is used only to a minor 
amount. A closed physical model of the process with clearly de- 
fined causal relationships between the process parameters does 
not exist. 

Quantitative and qualitative knowledge. 

If a process has n parameters, some points in the n-di- 
mensional parameter space can be determined exactly by experi- 
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ments. These are quantitative data. But even if the number of 
entries in the data tables is large, they only define single 
points in the parameter space and nothing is known about the re- 
gions surrounding them. In most cases however, it can be expec- 
ted that experiments yield still more information which tells us 
something about trends in the change of parameter values and in- 
fluences of parameters on others in qualitative terms. This part 
of the knowledge is usually represented as rules, as in the de- 
scription of the welding process. 

Estimations on the plausibility of the knowledge. 

The qualitative part of the knowledge achieved by experi- 
ments is open for interpretations when the relationships between 
the parameters are not or cannot be exactly specified. In this 
case, the plausibility of the qualitative propositions can be 
estimated by experts in different ways. They do so on grounds of 
their experience. This is another knowledge source which yields 
some kind of meta-level knowledge. 

4 Qualitative reasoning in the system PEPS 

The central one of the problems mentioned in section 3 is 
the combination of quantitative and qualitative values. In PEPS 
(plausibility estimating process stimulator) , a compromise is 
made between both. For each parameter it is assumed that its 
possible values have an upper and a lower bound. Its qualitative 
value space is subdivided into n segments of equal length, 
called "increments". Thus the values of the parameters are in 
fact qualitative, but they tend to be quantitative. Therefore, 
they can be called "quasi-quantitative" . For n we have arbitra- 
rily chosen the value 100, the idea is to make a rather fine 
subdivision. The interval of really quantitative values between 
the upper and lower bound of a parameter is mapped on the quasi- 
quantitative value space of the parameter in a natural way. 

Using this mapping, the exact parameter values available from 
the data tables can be easily assigned to quasi-quantitative va- 
lues. Thus the transition from quantitative to qualitative va- 
lues causes no problems. 

However, the transition in the opposite direction, or to 
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be more precise: from the qualitative values available from the 
rules to the quasi-quantitative values, is not so easy. The 
parameter values occuring in the rules are really qualitative, 
i.e. only a small number of values is specified, and, regarding 
them as representing any intervals on the real line, they usu- 
ally represent intervals of different lengths. Mappings like in 
the first case cannot be defined. Assignments of qualitative to 
quasi-quantitative values must therefore be viewed as assump- 
tions. The user of PEPS has to make such assumptions, and they 
have the form of "proportionality factors" (arbitrary values) 
and of "plausibility values" (PV? ranging between 0.1 and 1). 

In addition, he/ she has to define those parameters that have any 
influences on others. The rules provided with such assumptions 
therefore form some hypothetical part of the knowledge. By expe- 
riments the borderline between the certain knowledge and the 
hypothetical knowledge can be pushed forward in favor of the 
certain part. This is illustrated in figure 3. In the beginning, 
almost all rules are hypothetical. By experiments, they get more 
and more certain and are eventually modified. 



Knowledge 




Figure 3: Increasing the certain knowledge by experiments. 



The following example demonstrates the use of proportio- 
nality factors and plausibility values. Take the first rule 
mentioned in section 2: 

"The melting-off efficiency is proportional to the wire 
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diameter and the wire speed." 

In the literature, four specializations of this rule 
(among others) can be found: 

(1) IF wire-diameter = 8 AND wire-speed = 1 
THEN melting-off-efficiency := 2.36 
(PV = 1) 

(2) IF wire-diameter = 8 AND wire-speed = 6 
THEN melting-off-efficiency := 2.36 * 6 
(PV = 1) 

(3) IF wire-diameter = 12 AND wire-speed = 1 
THEN melting-off-efficiency := 5.32 

(PV = 1) 

(4) IF wire-diameter = 12 AND wire-speed = 6 
THEN melting-off-efficiency := 5.32 * 6 
(PV = 1) 

All these rules are assumed to be certain, therefore the 
PV 1. Rules (1) and (2) and rules (3) and (4) respectively can 
be merged together by an obvious generalization. This yields the 
rules (5) and (6) : 

(5) IF wire-diameter = 8 

THEN melting-off-efficiency := 2.36 * wire-speed 
(PV = 0.8) 

(6) IF wire-diameter = 12 

THEN melting-off-efficiency := 5.32 * wire-speed 
(PV = 0.8) 

Rules (5) and (6) are more general in so far as they 
claim to hold for arbitrary wire-speeds. We are not quite sure 
about this fact, therefore the PV 0.8. Now rules (5) and (6) can 
be merged into rule (7) , generalizing the wire-diameter: 

(7) IF wire-diameter > 4.8 

THEN melting-off-efficiency := (wire-diameter - 4.8)* 

0.74 * wire-speed 

(PV = 0.5) 

This rule represents a linear extrapolation of the values 
in the first and second interpretation. However, we are less 
sure about the plausibility of this rule, because a better 
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extrapolation might be some curve through the two points marked 
by (5) and (6). 



If rule (7) is used for a number of process simulations, 
this will yield a set of values of the resulting parameters. The 
results may be proved by experiments and as a consequence, the 
plausibility value of (7) will be increased or decreased. If it 
has to be decreased, the user may modify the rule in order to 
get better results. 



In general, we distinguish two types of rules, reflexive 
and non- ref lexive ones, depending on the action part of the 
rule. This part consists of a value assignment to a parameter p 
of the form p := f (ql , . . . , qm) . If p € {q1,...,qm}, the rule is 
called reflexive, otherwise non-reflexive. A set of rules R = 
{r1,...,rn} is called non-reflexive, if each ri is non-reflexive 
(i = 1,...,n), otherwise it is called reflexive. If s is a rule 
or a parameter, PV(s) is its plausibility value. If a rule r has 
an action part of the form p := f (ql , . . . , qm) , then AV (ql , . . . ,qm) 
is the average of the plausibility values of q1,...,qm, i.e. 

m 

AV(q1 , . . . ,qm) = £ PV(qi) /m 
i= 1 

Assume the assignment p := f (ql , . . . ,qm) is the action 
part of rule r and p_Old is the value of p before and p_New the 
value of p after evaluation of the rule. Then the plausibility 
value of p is computed by the following function: 



PV(p) 



= < 



PV(r) * AV(q1 , . . . ,qm) if r is non-reflexive 

p_01d*PV (p) + |p_New-p_01d|#PV(r )*AV (ql , . . . ,qm) 

p_01d+ | p_New-p_01d | 

if r is reflexive 



Notice that p_New has already been computed when the new 
plausibility value of p is determined. The idea behind the defi- 
nition of PV(p) in the reflexive case is to let PV(p) depend on 
the PV l s of the influencing parameters only to some degree that 
is determined by the rate of change of the value of p. 



The rules themselves are processed in the following way: 
If an influencing parameter qi changes its value by k incre- 
ments, then k is taken as a measure for the speed of change, 
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i.e. as the value of the derivative of qi w.r.t. time. The rule 
set assigned to a parameter p that is influenced by qi, is then 
evaluated k times. Take as an example the rule set consisting of 
(8) and (9): 

(8) IF B > 30 AND A > 0 THEN B := B + 0.4* A 

(9) IF B £ 30 AND A > 0 THEN B := B + 0.5*A 

and assume that the value of A is 10, the value of B is 
20, A influences B and A rises by 10 increments. Then the value 
of B is computed as follows: 

B_New = B_01d + 0.5*11 + 0.5*12 + 0.4*13 + ... + 0.4*20 
= 84.3 

We have used the same scale of increments for the para- 
meters and their derivatives in this example for simplicity. In 
general, there may be used different scales, and then the change 
of the parameter value has to be mapped on the scale for the 
derivative values by an appropriate function. 

5 Definition of processes 

Processes are defined on the set of process parameters. 

A process parameter is a triple 

p = (v, pv, R) 

where v is the quasi-quantitative value of p, pv its 
plausibility value, i.e. pv = PV(p), and R a rule set assigned 
to p. By the rule set, the value v is computed if some of the 
influencing parameters change their values, as it is described 
in section 4. At the same time, pv is computed with each rule 
evaluation by the function PV, defined in section 4. 

A process P is a directed graph 
P = (PAR, E) 

where PAR is a set of process parameters and E £ PAR*PAR . 

For (p,q) € E, we say that p influences q and q is in- 
fluenced by p. If a node has no ingoing edge, it is called an 
inport , if it has no outgoing edge, it is called an outport . 
Figure 4 shows an example of a process. 
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Aggregates are composed of modules, which are themselves 
aggregates or processes. A set of modules {Ml , . . . ,Mn} is compo- 
sed to an aggregate by identifying some of the outports with 
some of the inports of the modules in such a way, that each in- 
port is identified with at most one outport. After this identi- 
fication step, some of the free inports and outports are defined 
as inports and outports respectively of the aggregate. Notice 
that some of the free inports and outports may remain free in 
the aggregate 

PEPS is implemented in LOOPS on a Siemens EMS machine. 
Figure 5 shows the configuration of PEPS. The communication with 
the system is graph based, only for the rules verbal input is 
needed. The graphical I/O-routines handle standardized gauges 
for the quasi-quantitative parameter values. This is sufficient 
for the simulation of all types of processes that can be repre- 
sented in PEPS. If the user wants to implement more comfortable 
I/O-routines, perhaps including a special graphical representa- 
tion of the process and its parameters, he/she can make use of 
the special interface for user defined I /O-functions . In addi- 
tion to its comfortable operating surface, PEPS is able to 
accept actual values from a really running process on a techni- 
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cal system and to output commands for the change of adjustments 
in the system. 

The process graph is constructed in PEPS in an inter- 
active manner by means of the process definition component. 
First, the parameters and the influences between them are speci- 
fied. Then, to each parameter (i.e. node) a set of rules is as- 
signed. For both steps special editors are available. The graph 
is processed breadth-first, starting from the nodes with no in- 
going edge, i.e. the adjustable parameters. Evaluation of a node 
means evaluation of its rule set. One of the rules with the best 
PV and whose condition is satisfied (usually, this is exactly 
one rule) is applied. A free inport causes a request for a value 
to the user. 
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6 Conclusion 

We have described the expert system PEPS, that is aimed 
to model and simulate processes of a certain type. These pro- 
cesses have the property that the knowledge about them is achie- 
ved by experiments, is composed of quantitative and qualitative 
data, and is subject to plausibility estimations. The automatic 
welding process is an instance of this type of processes. 

Some interesting problems are left open. For example, if 
the data tables are stored in a data base, the valuation of the 
result of a deduction could be done automatically. For this pur- 
pose, small surroundings of the data table entries, conceived as 
points in the n-dimensional parameter space, should be defined, 
and if the values of the adjustable parameters from which the 
deduction starts together with the derived values of the resul- 
ting parameters - forming another point in the parameter space - 
fall into one of these surroundings, then the result, the rules 
used in the deduction, and the assumptions can be estimated as 
good. If they do not, some of the assumptions could be retracted 
and replaced with others. To avoid a completely new deduction in 
this case, starting from the scratch, a reason maintenance sy- 
stem would be useful. 

Another open problem is time. There is no representation 
of time in PEPS, though this seems to be necessary when proces- 
ses are aggregated. The idea to incorporate time representation 
in PEPS will lead to a more detailed process definition on the 
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WISSENSBASIERTE SUCHE IN PROJEKTBIBLIOTHEKEN 
Michael Wächter, ESG Elektronik-System-Gesellschaf t mbH 



ZUSAMMENFASSUNG : 

Zukünftige computergestützte Entwicklungswerkzeuge sollten 
die Möglichkeit beinhalten, die in bereits abgeschlossenen 
Projekten erarbeiteten Ergebnisse in stärkerem Maß zu nutzen, 
als das heute üblich ist. Dazu ist es nötig, Ähnlichkeiten 
zwischen Produkten und Produktteilen festzustellen. Die Ent- 
wicklung eines Projektadvisors mit dieser Eigenschaft kann 
mit wissensbasierten Techniken vereinfacht werden. Unsere Er- 
fahrungen mit einem einfachen Prototypen zeigen, daß unmit- 
telbarer Zugriff zu den Projektbibliotheken der abgeschlosse- 
nen Projekte nötig ist. 

SCHLÜSSELWÖRTER: Software Engineering, Prototyping, 

Auskunft, Kopplung mit konventioneller 
Datenverarbeitung 



1. EINLEITUNG 

Nach dem Einsatz von wissensbasierten Techniken, insbesondere 
von Expertensystemen, in Anwendungsgebieten der EDV, wie 
medizinischer Diagnose, Sitzplatzreservierung und ölsuche 
dringen diese Techniken zunehmend in die EDV selbst vor, mit 
dem Ziel einer Verbesserung des System Engineering. Die in den 
Firmen vorhandenen Erfahrungen sollen stärker genützt werden, 
Mehrfachentwicklungen sollen vermieden und der Wissensstand 
der Firmenmitglieder vereinheitlicht und erhöht werden. Bei 
der SW-Entwicklung z.B. ist der Weg vorgezeichnet in Richtung 
einer SW-Fabrik, in der der SW-Entwicklungsprozess mehr einem 
Konfigurieren von Modulen aus umfangreichen Bibliotheken 
gleicht, und die Arbeit des SW-Entwicklers aus Suche und An- 
passung besteht. Auch bei der Mikroelektronik gehen seit lan- 
gem die Bemühungen in die gleiche Richtung (Stichwort: 

Customer Design) • 
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2. DAS VERBÜNDPROJEKT PROSYT 

Dieses Ziel wird neben anderen im vom BMFT geförderten Ver- 
bundprojekt PROSYT (Integriertes Entwurfs- und Software-Pro- 
duktionssystem für verteilbare Realzeit-Rechnersysteme in der 
Technik) verfolgt £ 4 ] . In diesem Projekt arbeiten unter der 
Leitung der Fraunhofer-Gesellschaft Werkzeughersteller, Anwen- 
der und Hochschulinstitute zusammen, um eine Systementwick- 
lungsumgebung zu entwickeln, die neben einem Bündel von Ent- 
wicklungswerkzeugen mit einheitlichen Bedien-und Datenhal- 
tungsschnittstellen eine wissensbasierte Komponente, den soge- 
nannten Pro jektadvisor , enthält. Bild 1 zeigt die Architektur 
von PROSYT mit den Merkmalen: 

- Kopplung verschiedener Werkzeuge 

- einheitliche Dialogschnittstelle 

- einheitliche Datenhaltung 

- Projektadvi sor. 

Der Projektadvisor wird unter Führung des IRP (Institut für 
Regelungstechnik und Prozessautomatisierung, Universität 
Stuttgart) und unter Beteiligung des Ifl (Institut für Infor- 
mationsverarbeitung, ebenfalls Universität Stuttgart) und der 
Firmen AEG, Bosch, Contraves, Dornier System, ESG und GPP ent- 
wickelt. Das Ergebnis der gemeinsamen Arbeiten wird im wesent- 
lichen aus einem Softwarepaket und aus einer Menge von Verfah- 
ren, die von diesem Softwarepaket unterstützt werden, beste- 
hen. Der Kern der Software wird ein Expertensystem-Shell-ähn- 
liches System sein, mit dem in der Wissensdefinitionssprache 
PATHOS formulierte Wissensbanken verwaltet und verarbeitet 
werden £ 3 ] . Das System wird in SYSLAN implementiert und wird 
zunächst auf der VAX unter VMS, später auf allen Rechnern, auf 
denen EPOS ( Entwicklungs- und Pro jektmanagement-orientiertes 
Spezifikationssystem) ablauffähig ist, verfügbar sein. Die zu 
entwickelnden Verfahren werden die Projektarbeit im obigen 
Sinn, also in Richtung mehr ingenieurmäßiger Arbeitsweisen, 
unterstützen und werden drei verschiedene Arten von Wissen be- 
rücksicht igen: 
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- Vorschriften, Richtlinien, Normen 

- Erfahrungswissen 

- Wiederverwendbare Projektergebnisse. 

Dieser Bericht beschränkt sich auf die Thematik der Wiederver- 
wendung von Projektergebnissen. Der Einsatz eines automati- 
sierten Projektadvisors ist dann sinnvoll, wenn in einer Firma 
viele Projekte bzw. Produkte ähnlichen Charakters abgewickelt 
bzw. entwickelt werden und das Wissen darüber so über die Fir- 
ma verteilt ist, daß i.a. kein unmittelbarer Zugriff zu diesem 
Wissen besteht. Das ist in heutigen Großfirmen mit ihren räum- 
lich und organisatorisch weitverzweigten Strukturen der Fall. 
Immer wieder ist festzustellen, daß an Aufgaben gearbeitet 
wird, für die in ähnlicher Problemstellung bereits Lösungen 
vorliegen, die nur leichter Änderungen bedürfen. Dabei ist die 
Sicht auf Brauchbares oft versperrt durch zu starre und un- 
intelligente Suchverfahren. 

Die Firma ESG erstellt ein System, mit dem untersucht wird, 
inwieweit sich wissensbasierte Techniken dazu eigenen, die 
Suche nach wiederverwertbaren Projektergebnissen zu unterstüt- 
zen. Dieses System verwaltet Produkte, für die eine sehr ein- 
fache modulare Struktur vorausgesetzt wird. Ein Produkt be- 
steht aus Komponenten. Die Komponenten können Geräte oder Pro- 
gramme sein, wobei letztere wiederum aus Modulen bestehen. 
Typischerweise kann es sich bei diesen Produkten also um Sy- 
steme handeln, wie sie in Systemhäusern wie ESG oder Dornier 
entwickelt werden. 

Unser System entsteht in mehreren Stufen. Zunächst wurde ein 
Prototyp mit stark eingeschränktem Anwendungsgebiet auf einer 
LISP-Maschine der Firma SYMBOLICS realisiert. Im nächsten 
Schritt wird dieser Prototyp nach PATHOS übertragen, und das 
Anwendungsgebiet wird ausgeweitet. 




453 



3. EIN BEISPIEL 

Der Entwickler oder Angebotsverfasser, der ein neues Projekt 
oder Produkt angeht, wird sich existierende Produkte ansehen, 
wird sie vergleichen und auf ihre Brauchbarkeit prüfen. Beim 
heutigen Stand der Technik muß er dazu ein gehöriges Maß an 
Erfahrung und Wissen mitbringen, um im Archiv die richtigen 
Dokumente zu finden, in einer Projektbibliothek den richtigen 
Modul zu finden oder bei einer Bibliotheksrecherche die rich- 
tigen Schlüsselwörter anzugeben. Gewußt wo! heißt die Devise, 
und der Erfolg beim Suchen kann über den Erfolg des Projektes 
entscheiden. 

Die Unterstützungsmöglichkeiten sollen an einem bewußt extrem 
simplifizierten Beispiel erklärt werden. Die Abb. 2 bis 4 zei- 
gen drei Situationen, wobei in Situation I eine einfache Ar- 
chivdatei über abgeschlossene Projekte, in Situation II zu- 
sätzlich die Projekte beschreibende Information und in Situa- 
tion III darüber hinaus noch Wissen darüber abgelegt ist, wie 
diese Information zu benützen ist. In Situation I laufen 
z. B. die folgenden Arbeitsschritte ab: 

(1.1) Der Bearbeiter soll ein kommerzielles Programm für das 
Auftragswesen für den Rechner PCXYZ entwickeln. 

(1.2) Er weiß: Die Sprache COBOL ist geeignet für kommerziel- 
le Programme. Sie ist auf PCXYZ vorhanden. 

(1.3) Er weiß ferner: Das Programm PERSYS ist in COBOL ge- 
schrieben. Von diesem Progamm möchte er sich Anregungen 
holen. 

(1.4) Er fragt die Archiv-DB: 

SELECT Archiv-Nr 

FROM Projekte 
WHERE Name = "PERSYS" 

(1.5) Die Antwort des Systems: 

Archiv-Nr = 3107 

(1.6) Der Bearbeiter holt die Unterlagen für PERSYS aus dem 
Archiv. 
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(1/7) Er stellt fest: Das Programm PERSYS eignet sich nicht 
für seine Zwecke. Er macht alles neu und braucht 7 MM. 

Der Bearbeiter hat eine schlechte Ausbeute beim Suchen. Das 
ist anders im nächsten Pall II, in dem das System über be- 
schreibende Informationen über die Projekte verfügt. Obwohl 
der Bearbeiter überhaupt keine abgeschlossenen Projekte kennt, 
erfährt er vom System mehr: 

(11.1) wie (1,1) bis (1,3) 

(11.2) Der Bearbeiter fragt: 

SELECT Archiv-Nr 
FROM Projekte 

WHERE Sprache = "COBOL" 

(11.3) Die Antwort des Systems lautet: 

Archiv-Nr. = 3107 
Archiv-Nr. = 4559 

(11.4) Der Bearbeiter holt Unterlagen für PERSYS und COMPRO 
aus dem Archiv 

(11.5) Er stellt fest: Teile des Programms COMPRO können mit 
leichten Änderungen übernommen werden. Er braucht 4 MM 
für seine Aufgabe. 

Im folgenden Fall III wird der Bearbeiter mit noch weniger 
Wissen - er kennt nicht mal COBOL - das beste Ergebnis erzie- 
len: 

(111. 1) wie (1,1) 

(111. 2) Der Benutzer setzt sich vor den Pro jektadvi sor und 
wird nach einigen allgemeinen Fragen nach dem Typ des 
zu erstellenden Programms gefragt. Er antwortet: 
Programm ist kommerziell 

(111. 3) Das System antwortet: Da haben wir was im Archiv, was 
Ihnen von Nutzen sein könnte: 

Archiv-Nr. = 2646 
Archiv-Nr. = 3107 
Archiv-Nr. = 4559 
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(111.4) Der Bearbeiter holt die Unterlagen für PERSYS, COMPRO 
and AUPRO aus dem Archiv. 

(111. 5) Er stellt fest, daß schon einmal ein Auftragsabwickler 
AUPRO entwickelt wurde, der die Spezifikation des von 
ihm zu schreibenden Systems weitgehend erfüllt. 

Da PL/1, in dem AUPRO geschrieben ist, nicht auf der Maschine 
PCXYZ vorhanden ist, kann der Bearbeiter sich daran machen, in 
1 MM AUPRO nach COBOL umzuschreiben. Er kann sich aber vom 
Projektadvisor auch folgendermaßen beraten lassen: 

(111. 6) Der Bearbeiter beschwert sich: AUPRO läuft nicht auf 
PCXYZ i 

(111. 7) Das System antwortet: Auf dem PCXYZ gibt es COBOL. 
Versuchen Sie doch, AUPRO mit dem Programm-Transforma- 
tor PLCOB nach COBOL umzuwandeln. 

(111. 8) Der Bearbeiter braucht nur 1 MW, um den Rat des Pro- 
jektadvisors in die Tat umzusetzen und noch einige 
kleine Änderungen durchzuführen. 

Zusammenfassend kann man sagen, daß dadurch eine wesentliche 
Verbesserung der Suchergebnisse erreicht werden kann, daß vom 
Wissen, das ein Mitarbeiter präsent haben muß, der ein konven- 
tionelles Abfragesystem benützt, möglichst viel in das System 
verlagert wird. Ein besonderes Augenmerk verdient dabei die 
Möglichkeit, mit "weicheren" Regeln, wie z. B. die Regel R2 
von unten eine darstellt mit ihrem "fast alle", auch Ähnliches 
zu suchen und zu finden, ohne auf exakte Übereinstimmung ange- 
wiesen zu sein. 
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4. ÄHNLICHKEIT ALS MASS FÜR DIE WIEDERVERWENDBARKEIT 

Unser Prototyp beschränkt sich auf genau dieses Problem, den 
Vergleich von Produkten und Modulen auf Ähnlichkeit. Der Be- 
griff der Ähnlichkeit wird so stark herausgestrichen, weil man 
sich auch im normalen täglichen Leben beim Aufgreifen einer 
neuen Aufgabe intuitiv auf ähnliche Tätigkeiten rückbesinnt, 
deren Erfolg oder Mißerfolg abwägt und versucht, brauchbare 
Erfahrungen wieder umzusetzen. Die Fähigkeit, Ähnlichkeiten zu 
erkennen und Analogien zu bilden, ist eine der wesentlichen 
Grundlagen für intelligentes Verhalten überhaupt und für den 
Erfolg des Menschen in der Evolution, 

Es ist schwierig, wenn nicht unmöglich, ein allgemeingültiges 
quantitatives Maß und ein damit verbundenes Berechnungsver- 
fahren für die Ähnlichkeit z. B. von Softwaremodulen zu ent- 
wickeln. Der im Bereich der Dokumentationssysteme eingeführte 
Begriff der Relevanz und die damit in Zusammenhang stehenden 
Maße lassen sich nicht unmittelbar übertragen, da mit Ihnen 
die Qualität der Dokumentation als Ganzes in Bezug auf be- 
stimmte Anfragen beschrieben wird £l]. Anders geartet ist die 
Frage, ob zwei Module unterschiedlicher Aufgabenstellung, die 
beide in PASCAL geschrieben sind, einander ähnlicher sind als 
zwei Module, die beide Eingabedaten sortieren, aber in COBOL 
und ASSEMBLER geschrieben sind. Ist es sinnvoll, so etwas wie 
ÄHNLICHKEIT (MODULI, M0DUL2 ) =0,63 ausrechnen zu wollen? 

Solch ein eindimensionaler, mit einem einzigen Zahlenwert ver- 
bundener Ähnlichkeitsbegriff hat zuwenig Transparenz für den 
Benutzer und ist deshalb nur eingeschränkt brauchbar. Die Ver- 
suche unseres Prototypings haben jedoch ergeben, daß ein an- 
wendungsspezifischer Begriff von Ähnlichkeit im Sinn von 
"Brauchbarkeit unter bestimmten Gesichtspunkten" durchaus sei- 
nen Sinn hat. Die wissensbasierten Techniken ermöglichen rela- 
tiv einfache Vorgehensweisen, einen solchen Ähnlichkeitsbe- 
griff über Regeln zu definieren, mehrere Module in eine Ähn- 
lichkeitsreihenfolge bzw. Interessantheitsreihenf olge zu brin- 
gen und damit dem Benutzer den Suchvorgang zu erleichtern und 
brauchbare Resultatmengen zu liefern. 
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5. FORMULIERUNG VON ÄHNLICHKEIT DURCH REGELN 

In unserem Prototypen werden beim Vergleich zweier Produkte 
oder Module neben einem Wert auf einer einfachen Ähnlichkeits- 
skala Merkmale geliefert. Zwei Produkte können sich also z. B. 
als ähnlich erweisen mit dem Merkmal Sprache, was bedeutet, 
daß beide in der selben Sprache geschrieben wurden, oder als 
sehr ähnlich mit den Merkmalen Sprache, Aufgabenstellung und 
Auftraggeber. Zunächst muß der Benutzer unseres Prototypen das 
Produkt, zu dem ähnliche Produkte gefunden werden sollen, be- 
schreiben. Dann wird mit der Verarbeitung zweier Regelpakete 
begonnen. Sie werden durch Rückwärtsverkettung ausgewertet: 

- Mit dem ersten Regelpaket werden Kriterien für die zu ver- 
gleichenden Produkte festgestellt wie "gleicher Auftrag- 
geber", "Moduln in gleicher Sprache geschrieben", 

- dann wird aufgrund der gefundenen Merkmale der Ähnlichkeits- 
grad bestimmt. 

Quasi-verbal formuliert und der Einfachheit halber eine Ähn- 
lichkeitsskala mit nur drei Stufen vorausgesetzt (sehr ähn- 
lich, ähnlich, nicht ähnlich) , können einfache Regeln der Wis- 
sensbank z. B. folgendermaßen lauten: 

Rl : Zwei Module Ml und M2 sind sehr ähnlich mit den Merkmalen 
Sprache und Aufgabe, wenn (Sprache von Ml) = (Sprache von 
M2) und (Aufgabe von Ml) = (Aufgabe von M2). 

R2: Zwei Produkte sind sehr ähnlich, wenn fast alle Komponen- 
ten ähnlich sind. 

R3 : Zwei Produkte sind ähnlich mit Merkmal Sprache, wenn ir- 
gend zwei Module ähnlich mit Merkmal Sprache sind. 

R4 : Zwei Module Ml und M2 sind ähnlich mit dem Merkmal Spra- 
che, wenn (beide in einer kommerziellen Sprachen geschrie- 
ben sind) . 

R5 : Zwei Produkte sind sehr ähnlich mit Merkmal BS, wenn gilt, 
daß (die Programme jedes Produktes unter der selben Ver- 
sion von UNIX ablauffähig sind) . 
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Die Regeln des Prototypen bestehen aus mehreren Paketen, die 
entsprechend der Produktstruktur zuständig sind für die Modul- 
ähnlichkeit, die Komponentenähnlichkeit und, auf oberster 
Stufe, die Produktähnlichkeit. 

Regeln von der Art der Regel Rl überschreiten die Möglichkei- 
ten, die ein sachkundiger Benutzer mit einem konventionellen 
Abfragesystem hat, nur insoweit, als auch ein ungeübter Be- 
nutzer zu in Bezug auf die Aufgabenstellung der Suche nach 
brauchbaren früheren Arbeitsergebnissen zu sinnvollen Abfragen 
hingeleitet wird. Die sich hinter Regeln R2 und R3 verbergen- 
den Suchaufgaben lassen sich grundsätzlich ebenfalls in kon- 
ventionellen Abfragesystemen bewerkstelligen. Ihre Formulie- 
rung stellt jedoch eine relativ komplexe Aufgabe dar, so daß 
der Benutzer sich, diese gern vom Expertensystem abnehmen läßt 
(entsprechend ist auch die Formulierung solcher Regeln mit den 
Sprachmitteln einer ES-Shell oder in LISP nicht ganz einfach. 
Instanzvariable und den Quantoren der Prädikatenlogik äquiva- 
lente Sprachmittel sind notwendig). Die simple Aussage von 
Regel R4 sollte nicht darüber hinwegtäuschen, daß Regeln die- 
ses Typs die Möglichkeiten eines konventionellen Abfragesy- 
stems insoweit überschreiten, als hier echtes Expertenwissen 
- nämlich: Suche nicht nur nach COBOL, sondern auch nach ande- 
ren kommerziellen Sprachen wie PL/1 - zur Verbesserung der 
Suchstrategie herangezogen wird. Regel R5 schließlich ist ein 
Beispiel einer Randbedingung, wie sie auch der geübte Benutzer 
eines konventionellen Abfragesystems leicht einmal vergessen 
kann. In diesem Fall hebt das Expertensystem die Qualität des 
Suchergebnisses durch Einschränkung. 
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6 . FAKTENDARSTELLUNG 

Das Wissen über Produkte ist in der Wissensbank selbst in Form 
von Instanzennetzen dargestellt/ deren Knoten Instanzen der 
Frames PRODUKT , KOMPONENTE, GERÄT, PROGRAMM und MODUL sind. 

Des weiteren hat es sich als für die Formulierung der Regeln 
und die Verarbeitung vorteilhaft erwiesen, einen Frame ÄHN- 
LICHKEIT mit Instanzen einzuführen, die die jeweils interes- 
sierenden Produktpaare beschreiben. 

Die Frames können u.a. folgende Slots haben: 

PRODUKT: Auftraggeber, Zeitpunkt der Inbetriebnahme, Auf- 

wand, Anzahl der Installationen, Benutzertyp, Li- 
ste der Geräte (diese Art von Listen könnte auch 
durch gesonderte Instanzen von Relationen wie 
PRODUKT-ENTHÄLT-GERÄT dargestellt werden) , Liste 
der Programme 

KOMPONENTE: Hersteller, Preis 

GERÄT: Typ, Größe, verwendete Technologie 

PROGRAMM: Typ (z. B. Real-Time, Batch), Verarbeitungsklasse 

(z. B. Kommunikation, Textverarbeitung), Größe in 
LOC (durch Behavior berechnete Summe der LOC der 
Moduln) , Liste der Module 

MODUL: Sprache, Aufgabe (z. B • Input, Output, Sortie- 

ren), Größe in K, Größe in LOC 

ÄHNLICHKEIT: Produktbeze ichner-1 , Produktbezeichner-2 , Liste 
der Ähnlichkeitsmerkmale, Ähnlichkeitsgrad, 
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7. BEISPIELDIALOG 

Ein wesentlich verkürzter Dialog mit unserem Prototyp kann 
z. B. folgendermaßen aussehen (Benutzereingaben sind unter- 
strichen, sie werden i.a. aus Menüs ausgewählt): 

Sie können ein neues Produkt bzw. System definieren, das mit 
den in der Wissensbank beschriebenen Produkten verglichen 
wird. 

Wollen Sie Angaben zum Produkt als Ganzes machen? JA 
Wann findet oder fand die Inbetriebnahme statt? Unbekannt 
Wer ist der Auftraggeber des Produktes? BMFT 
Welches Betriebssystem wird verwendet? UNIX 
Welche Geräte werden verwendet? (VAX, VT100 ) 

Enthält das Produkt auch Software? JA 
Sie können mehrere Programme beschreiben. 

Wer ist der Hersteller des ersten Programmes? UAN 

Welcher Klasse gehört das Programm an? Kommerziell 

In welcher Sprache ist das Programm geschrieben? COBOL 

Was ist die Aufgabe des Programmes? RECHNUNGSWESEN 

Wollen Sie einzelne Module beschreiben? Nein 

Wollen Sie Angaben zu einem weiteren Programm machen? Nein 

Ein ähnliches Produkt ist: ERW 

Die Merkmale sind: GERÄT/SPRACHE 

Ein sehr ähnliches Produkt (System) ist: SYMA 

Die Merkmale sind: AUFGABE/GERÄT/SPRACHE 
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8. DIREKTER ZUGRIFF ZU PROJEKTBIBLIOTHEKEN 

Beim Aufbau eines für den echten Einsatz geeigneten Experten- 
systems der in diesem Artikel behandelten Aufgabenstellung 
stellt sich die Frage , wo das Wissen über Projekte und Pro- 
dukte herkommt und wo es in Zukunft lokalisiert sein soll. 

Es kommt aus den exist ierenden, DV-ges tützten Projektbiblio- 
theken und kann noch ergänzt werden durch bewertende, be- 
schreibende und die Erfahrung mit dem Produkt erfassende In- 
formation. Während diese zusätzliche Information in der Xtfis- 
sensbank des Expertensystems abgelegt werden sollte, zeigt 
sich, daß für die eigentliche Projektinformation die Wissens- 
bank selbst nicht der geeignete Ort ist, und daß auch eine 
Transformation in diese ungeeignet ist. Nötig ist ein unmit- 
telbarer Zugriff auf die bereits existierenden Projektbiblio- 
theken. Das soll kurz vertieft werden: 

Im Prototyp ist alles für das Auswerten der Regeln notwendige 
Fakten-Wissen in der Wissensbank selbst definiert. Das bedeu- 
tet z.B., daß das Wissen über das Vorhandensein eines bestimm- 
ten Programms und über dessen Programmiersprache sich nieder- 
schlägt in einer Instanz des Frames Programm bzw. einem Slot 
dieser Instanz in der Wissensbank. Diese Instanz kann dann in 
Regeln der selben Wissensbank angesprochen werden, z. B. da- 
durch, daß der Wert eines ihrer Slots mit einem in der Regel 
genannten Wert übereinstimmt. Auf das eigentliche Objekt des 
Interesses, nämlich das Programm selbst oder dessen Spezifi- 
kation, wird zur Laufzeit nicht zugegriffen, sondern dieses 
ist durch den beim Aufbau der Wissensbank stattfindenden Ab- 
bildungsvorgang Spezifikation bzw. Programm — » Instanz verbor- 
gen. Es ist nach Benutzung des Expertensystems auffindbar 
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durch Ref erenzierung, d.h. der Instanznahme oder ein beson- 
derer Slot EXTERNE-REFERENZ verweist auf das Wissensbank-ex- 
terne Objekt, auf das der Benutzer in einem gesonderten Ar- 
beitsgang zugreifen muß. Beim Aufbau einer solchen Wissens- 
bank müssen die externen Projektbibliotheken (das können z.B. 
EPOS-Datenbanken sein) in einem eigenen Arbeitsgang aufberei- 
tet, auf Brauchbares durchsucht, und die Aussagen über die ge- 
fundenen brauchbaren Ergebnisse in der Wissensbank separat von 
den Projektbibliotheken abgespeichert werden (Abb. 5.) Das 
stellt eine echte Doppelbelastung für die Projektmitarbeiter 
dar, verringern die Akzeptanz der Wissensbank bzw. des Exper- 
tensystems bei diesen und kann darüber hinaus zu Inkonsisten- 
zen und Fehlern führen. 

Deshalb sollte zumindest an eine Automatisierung dieses Über- 
tragungsvorgangs gedacht werden (Abb. 6). Die Übertragungs- 
funktion könnte alle Informationen der Projektbibliotheken, 
die formalen Regeln unterliegen (in EPOS die DECOMPOSITION-, 
IMPORT-, EXPORT-, INPUT- und OUTPUT-Abschni tte) , auswerten und 
daraus Einträge in der Wissensbank machen. Auch wenn eine 
automatisierte Übertragungs funkt ion dieser Art möglich ist, 
verbleiben einige Schwachstellen: 

- Das Wissen über hierarchische und andere strukturelle Bezie- 
hungen von Objekten in der Wissensbank ist redundant, da in 
den Projektbibliotheken noch einmal vorhanden. 

- Zwischen Projektbibliothek und WB können darüber hinaus In- 
konsistenzen auf treten, wenn z. B. erstere aktualisiert und 
die WB nicht nachgefahren wird. 

- Große Teile der Projektbibliotheken sind nicht genügend for- 
malisiert, um auf einfache Weise automatisch in die Wissens- 
bank übertragen werden zu können. 

- Während die Übertragung struktureller Beziehungen eine eher 
triviale Aufgabe ist, stellt die Übertragung der Aufgabenbe- 
schreibungen und anderer inhaltlicher Gesichtspunkte eine 
nichttriviale, beliebig komplexe Aufgabe dar. Eine theore- 
tisch denkbare Aufbereitung der gesamten textuellen Informa- 
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tionen der Projektbibliotheken würde außerdem eine Wissens- 
bank ganz immensen Umfanges erzeugen. 

Im Zusammenhang mit dem letzten Punkt muß berücksichtigt wer- 
den, daß die üblichen ES-Shells in der Sprache LISP geschrie- 
bene Hauptspeichersysteme sind. Der auf LISP-Maschinen vorhan- 
dene Hauptspeicher kann zwar groß sein (z.B. 30 MB), doch ist 
er begrenzt, während die auf Hintergrundspeicher abgelegten 
Projektbibliotheken im Prinzip der Größe nach unbegrenzt sind. 
Eine Abschätzung des Umfangs der in einer großen Firma vorhan- 
denen Projekt Informationen zeigt sehr schnell die Grenzen der 
derzeitigen Hauptspeichersysteme auf. 

Der bessere Weg scheint deshalb zu sein, den Schritt "Extrak- 
tion allen Wissens aus der Pro jektdatenbank" überhaupt zu um- 
gehen und von off-line- zu on-line-Zugrif f zu den Projektda- 
'renbanken überzugehen. Dann hat man in der Wissensbank nur 
beschreibende Informationen über 

- Formalismen des Projektentwicklungstools 

- firmenspezifische formale Erweiterungen, sofern solche vor- 
handen sind (es kann z.B. durchaus sinnvoll sein, den EPOS- 
DESCRIPTION-Te il firmeneinheitlich zu standardisieren). 

Ein zukünftiger Pro jektadvisor sollte die Projektdatenbanken 
mit Hilfe dieser Informationen unmittelbar lesen und verstehen 
können (Abb. 7). Es muß also ein Interface gebaut werden, das 
einen direkten Zugriff auf diese Datenbanken erlaubt. Z. B. 
müssen die in den Regeln Rl bis R4 oben geklammerten Ausdrucke 
durch Zugriffsfunktionen realisiert werden. 

Zusätzlich zu dem für den Zugriff zu den Projektbibliotheken 
notwendigen Wissen können vorhanden sein und müssen beim Auf- 
bau der WB separat eingebracht werden: 

- Metawissen über den Inhalt der Projektbibliotheken 

- "Wissen, das aus Bewertungen der Pro jektbibliotheks-Ob jekte 
stammt . 
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Diese Art von Wissen muß von den Projektmitarbeitern unmit- 
telbar stammen und manuell in die WB eingegeben werden • 

Der Wunsch nach unmittelbarem Zugriff macht allerdings ein 
weitergehendes on-line-Halten von Projektbibliotheken abge- 
schlossener Projekte notwendig, als das heutzutage üblich ist. 
über diesen Trade-off muß jede Firma vor dem Hintergrund ihrer 
speziellen Anforderungen und Gegebenheiten nachdenken. Die ins 
Haus stehenden optischen Speichertechniken eröffnen da ganz 
neue Perspektiven. 

Der im Verbundprojekt PROSYT entwickelte Projektadvisor wird 
den hier geforderten Zugriff zu Projektbibliotheken und insbe- 
sondere die Auswertung dort gespeicherter Texte mit einem 
Hilfsmittel unterstützen, bei dem hierarchische, bewertete 
Strukturen von Suchbegriffen aufgebaut werden, sog. Umfelder 
£2^ • Mit diesen ist es z. B. möglich, festzustellen, daß mit 
einer gewissen Wahrscheinlichkeit von der VAX gesprochen wird, 
obwohl das Wort "VAX" im untersuchten Text nicht vorkommt, 
sondern die Worte "Computer" und "DEC". 

Für die Sprache PATHOS wurde außerdem zur besonderen Unter- 
stützung von EPOS die Erweiterung um eine Schicht vorgeschla- 
gen, die die Semantik der unterschiedlichen EPOS-Konstrukte 
ACTION, MODULE, EVENT, etc. wiederspiegelt. Die einzelnen 
EPOS-Konstrukte sind bereits mit einem gewissen Bedeutungs- 
spielraum behaftet, den sie im Entwurfsprozeß und im späteren 
Zielsystem haben können. In einer Sprache, die sich für die 
Formulierung von Metawissen über eine EPOS-DB eignen soll, 
müssen sich die Bedeutungen dieser EPOS-Konstrukte widerspie- 
geln, Sie muß Parallelkonstrukte zu den EPOS-Objekten enthal- 
ten, die es erlauben, Metaaussagen über entsprechende Objekte 
einer EPOS-DB zu machen. 
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9. ZUSAMMENFASSUNG UND SCHLUSSBETRACHTUNG 

Dieser Bericht erhebt nicht den Anspruch, ein vollständiges 
Konzept für einen Projekt Advisor darzustellen. Der darin be- 
schriebene Prototyp hat aber gezeigt, daß sich wissensbasierte 
Techniken durchaus dazu eignen, einen intelligenteren Zugriff 
zu dem in einer Firma vorhandenen Know-How und zu bereits vor- 
handenen Arbeitsergebnissen zu ermöglichen. Die im Prototypen 
gebotenen Möglichkeiten gehen zwar nicht wesentlich über ein 
konventionelles Abfragesystem hinaus, doch ist andererseits 
ein Weg aufgezeigt, mit relativ einfachen Mitteln die Be- 
schränkungen eines solchen Systems zu überwinden. Allein die 
Benutzerführung in den käuflichen ES-Shells mit z.B. der An- 
zeige aller möglichen Eingaben in Menuform und mit Erklärungen 
zum Dialogablauf bedeutet einen echten Qualitätssprung. 

Zum Vergleich von in Projektbibliotheken abgelegten Arbeitser- 
gebnissen und von eventuell wiederverwendbaren Projektteilen 
sind Ahnlichkeitsf unktionen von der im Prototyp realisierten 
Art notwendig. Eindimensionale Maßstäbe eignen sich nicht. Die 
zusätzliche Gewinnung kennzeichnender Merkmale scheint uns ge- 
eignet, auch wenn sie noch einer Verfeinerung bedarf. 
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Ein wesentliches Ergebnis unserer Arbeit ist, daß die voll- 
ständige Nachbildung der Projektbibliotheken einer Firma in 
Wissensbanken zumindest automatisiert vor sich gehen müsste, 
daß ein unmittelbarer Zugriff zu den externen Projektbiblio- 
theken jedoch die bessere Lösung darstellt. Alles formalisier- 
te und formalisierbare Wissen sollte in der ursprünglichen 
Form in den Projektbibliotheken belassen werden, in der Wis- 
sensbank selbst sollte nur das für die externen Zugriffe not- 
wendige Wissen und nicht formalisierbares Erfahrungswissen 
über die Projekte abgelegt werden. Die durch diese Philosophie 
notwendige umfangreiche on-line-Haltung von Projektbibliothe- 
ken abgeschlossener Projekte wird durch optische Speicherme- 
dien ermöglicht werden. 
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flbb.7 Wissensbank nit direkten Zugriff iur Projektbibliothek 
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Wissensbasierte Informationssysteme in einer 
wissensorientierten Industrie 

Uwe Hein 
Inf ovation GmbH 



Wissensbasierte Informationssysteme haben sich in letzter Zeit ein 
erstaunlich großes Interesse zugezogen. Das beweisen die zahlreichen 
nationalen und internationalen Förderungsprogramme, in denen es darum 
geht, die technischen Grundlagen für wissensbasierte Systeme 
weiterzuentwickeln und wissensbasierten Systemen zu einer praktischen 
Anwendung in der Industrie zu verhelfen. Das wird aber euch durch die 
zahlreichen Unternehmen bewiesen, die sich plötzlich in diesem Gebiet 
grosse kommerzielle Erfolge erwarten. 

Die Überzeugungskraft dieser jungen Technologie wird keineswegs 
dadurch verringert, wenn man gleichzeitig konstatieren kann, daß der 
Nutzeffekt von wissensbasierten Systemen in der Praxis nur in 
Einzelfällen bewiesen worden ist. Auf der anderen Seite sind die wenigen 
bekannten Erfolgsgeschichten aber auch oft genug erzählt worden. 
Betrachtet man eine globale Bilanz über Investition und Nutzen würde 
diese Tatsache sicherlich recht deutlich belegt werden können. 

Das Interesse an wissensbasierten Informationssystemen kann nur 
deshalb so groß sein, weil offensichtlich zentrale Probleme identifiziert 
werden können, für die dringend Lösungen gefunden werden müssen. 

Genauer gesagt geht es nicht nur um vereinzelte Probleme, die mit hilfe 
der neuen Technik gelöst werden könnten, sondern es handelt sich hier um 
einen bedeutenden Trend in unserer Gesellschaft, der zu einer 
zunehmenden Wissensorientierung unserer gesamten Wirtschaft führen 
wird. 

Unter Wissensorientierung verstehen wir in diesem Zusammenhang 
einen Prozeß, in dem Wissen immer mehr als strategischer Produktions- 
und Produktivitätsfaktor anerkannt und zu diesem Zwecke ausgenutzt wird. 
Dies gilt in gleicher Weise für Industrieunternehmen, die herkömmliche 
Produkte und Güter herstellen, wie Stahl oder Milch. Dies gilt aber auch 
für Betriebe, die hauptsächlich Wissen produzieren und vertreiben, etwa 
kvalifizierte Beratungsdienste oder die Vermittlung von Information. 
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Die zunehmende Wissensorientierung unserer Wirtschaft läßt sich an 
einer Reihe von Phänomenen illustrieren. Dazu gehören: 

* Das Funktionieren vieler Unternehmen ist in zunehmendem Maße von 
Wissen abhängig. 

* Eine ständig wachsende Zahl von Angestellten wird zu 
Wissensarbeitern. 

* Eine ständig wachsende Zahl von Betrieben wird sich direkt mit der 
Herstellung und dem Vertrieb von Wissen beschäftigen. 

* Ein Markt für Werkzeuge und Hilfsmittel, die zur Effekt! Visierung der 
Wissensbearbeitung und Wissensverwaltung beitragen entsteht. 

* Schon heute profilieren sich viele Unternehmen als "Wissensbetriebe" 



'Wenn aber Wissen zu einem der wichtigsten Produktivitätsfaktoren 
wird, dann sind die Wissensarbeiter - als die bisher einzigen produktiven 
Träger von Wissen - die kritischen Ressourcen in Betrieben. Der Bank- und 
Finanzsektor illustriert dies sehr deutlich. Die Unternehmen in diesem 
Bereiche sind sich sehr wohl der Bedeutung ihrer Goldarbeiter bewußt. 
Fortschrittliche Personalpolitik, attraktive Beteiligungen in der Form von 
Aktien oder Optionen und vergoldete Handfesseln sind in der Bransche 
übliche Mittel um kvalifizierte Mitarbeiter an ein Unternehmen zu binden. 

Aus der Perspektive eines Unternehmens muß eine solche Situation 
aber natürlich als großes Risiko und als potentielle Bedrohung erlebt 
werden. Hand in hand mit einer neuen Personalpolitik, neuen Führungsstilen 
und neuen Organisationsmodellen, die für die Leitung und Steuerung von 
Wissensbetrieben effizienter sind, geht daher auch die Suche nach neuen 
Technologien, die dazu beitragen können, diese und viele andere Probleme 
der Wissensindustrie zu lösen. 

Betrachtet man einige der Anwendungen von wissensbasierten 
Informationssystemen, so kann man leicht sehen welche grundlegenden 
Wissensprobleme mit dem System angegriffen werden sollen. Es geht 
darum: 

* Die Abhängigkeit von einzelnen Personen zu vermeiden oder zu 
vermindern 
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* Begrenzte personelle Ressourcen zu multiplizieren 

* Fragmentiertes Wissen und Erfahrungen zu vereinen 

* Große Wissenszusammenhänge überschaubar zu machen 

* Performanz auch unter Stress gewährleisten zu können 



* Produkte besser betreuen zu können 



* Intellektuelle Routineaufgaben zu automatisieren 

* Ungleiche Qualität zu vermeiden 

* Probleme trotz ungenügender Kompetenz lösen zu können 

Wir können mit gutem Recht erwarten, daß wissensbasierte 
Informationssysteme von zentraler Bedeutung sein werden für 
Unternehmen, die an dem Prozeß der Wissensorientierung teilnehmen. 
Gleichzeitig wäre es aber falsch anzunehmen, daß Wissensorientierung 
allein ein technologisches Problem sei und eine Herausforderung darstellt, 
die einzig und allein durch technische Verfahren gelöst werden könne. Hier 
bedarf es weiterer Perspektiven. 

Um den wirklichen Nutzen von wissensbasierten Systemen abschätzen 
und beweisen zu können, bedarf es einer verfeinerten Wissensökonomi. Die 
Kategorien, die heute zur Verfügung stehen um betriebswirtschaftliche 
Zusammenhänge zu beschreiben sind entwickelt worden mit Rücksicht auf 
den industriellen, güterproduzierenden Betrieb. Gewinn und 
Verlustrechnungen und Bilanzen in ihrer jetzigen Form können aber nicht 
unproblematisch auf wissensintensive Betriebe angewendet werden - eine 
Wahrheit, die in der Tat vielen Analytikern zu schaffen macht. 

Wissensbasierte Informationssysteme werden nicht einfach 
Wissensarbeiter in Betrieben ersetzen und von ihren Arbeitsplätzen 
verdrängen. Große, umfangreiche Systeme, die mit menschlichen Experten 
konkurrieren und als autonome Problemlösungssysteme eingesetzt werden 
könnten, werden nur einen Bruchteil von Anwendungen ausmachen. Die 
große Mehrheit von Anwendungen werden Systeme sein, die 
Wissensarbeiter produktiv in ihrer Arbeit unterstützen. Einen 
Rationalisierungseffekt kann man nur dann erhalten, wenn man die 
Wissensverarbeitung in einer organisatorischen Perspektive betrachtet 
und für eine optimale Synergie der verschiedenen Wissensträger sorgt. 
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Aus der Sicht der Kl als Grundlagenforschung sind solche Fragen, wie 
die der Wisssensökonomie oder die der betrieblichen Organisation von 
Wissen natürlich von sehr geringer Bedeutung. Aus der Perspektive des 
Praktikers, der wissensbasierte Informationssgsteme erfolgreich in die 
unternehmerische Wirklichkeit einbringen möchte sind solche Fragen von 
unerhörter Bedeutung. Die Schwieringkeiten, mit denen Projekte, die 
wissensbasierte Systeme in den heutigen Betrieben einführen wollen, zu 
kämpfen haben, sind nur zum Teil technische Probleme. Um ein 
erfolgreiches System zu konstruieren und in einen Betrieb zu integrieren, 
müssen nicht nur die technischen Probleme bewältigt werden. Auch für die 
betriebsorganisatorischen Fragen bedarf es positiver Antworten. 

Die große Herausforderung, die sich daher heute an die Technologie 
wissensbasierter Informationssysteme stellt, läßt sich am besten durch 
das Wort Integration beschreiben. Wissensbasierte Informationssysteme 
können zwar auf Inseln erfunden werden, sie können sich aber 
wirtschaftlich nur dann durchsetzen, wenn sie zum einen von realen 
unternehmerischen Problemen ( so wie sie vom Unternehmer erlebt werden 
I!) ausgehen, und zum anderen, wenn sie sich vollständig in die Welt 
integrieren, in der sie Probleme lösen sollen. Das erfordert aber ein 
globales Verständnis der Wissensverwaltung ("knowledge management") 
das über eine rein technische Perspektive weit . hinausgehen muß. 
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Abstract 

Second generation expert systems are able to combine heuristic reasoning based on rules, with 
deep reasoning based on a model of the problem domain. This solves a number of major problems of 
current expert systems, most importantly the problem of knowledge acquisition: second generation 
expert systems can learn new rules by examining the results of deep reasoning. The paper outlines 
the components of second generation expert systems and gives an example. 

1 . Introduction 

In the last decade significant advances in the study of Artificial Intelligence have given rise to a 
new class of computer programs called expert systems. Expert systems are programs capable of 
expert level performance in specialised fields. They constitute an important development in computer 
usage because they make a whole new class of problems amenable to computational treatment. 

The scientific, technological and business opportunities caused by this development are enormous. 
Many existing industrial and governmental organisations are now applying this new technology to 
their own aims, new businesses have sprung up, and expert systems have formed the subject of sub- 
stantial national and international research programs all over the world. 

What we see emerging today is a substantial jump forward in expert systems technology. The 
development is substantial because it touches on all aspects of an expert system: The nature of the 
potential problem domains, the type of reasoning being performed, the explanation capabilities, and 
most importantly the way knowledge acquisition is performed. 

In brief, whereas first generation systems rely purely on heuristic knowledge in the form of rules, 
second generation systems have an additional component in the form of a deeper model which gives 
them an understanding of the complete search space over which the heuristics operate. This makes 
two forms of reasoning possible: (1) the application of heuristic rules in a style similar to the classical 
expert systems, (2) the generation and examination of a deeper search space following classical search 
techniques, if there are no heuristics. 

A number of fundamental problems of current expert systems are solved using this extra complexity. 

+ First generation expert systems are brittle, in the sense that as soon as situations occur which fall 
outside the scope of the heuristic rules, they are unable to function at all. In such a situation, second 
generation system fall back on search which is not knowledge-driven and therefore potentially very 
inefficient. However, because these traditional search techniques can theoretically solve a wider class 
of problems, there is a graceful degradation of performance instead of an abrupt failure. 

-I- First generation systems base their explanations purely on a backtrace of the heuristic rules that 
were needed to find a solution. It is well known however that the path followed to find a solution 
usually differs from a convincing rational argument why the solution is valuable, particularly if a lot 
of heuristic knowledge entered into the reasoning process. Because second generation systems have 
access to a deeper understanding of the search space, they are capable to formulate a deeper and 
more convincing explanation which goes beyond the mere recall of which rules fired. 
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+ The most important advantage lies however in knowledge acquisition. Finding heuristic rules has 
turned out to be extremely difficult. Experts typically take a long time to come up with solid rules, 
the ruleset seems never complete, is continously changing and shows inconsistencies across experts 
(and even within the same expert). These inconsistencies are apparently due to different experiences 
which are the source of heuristic rule discovery. Second generation expert systems constitute a major 
jump forward in current technology because they exhibit learning behavior in the sense that they are 
capable to acquire new heuristic rules. 

The need for a new generation of expert systems has been felt for quite a while by various authors. 
An important milestone paper in this respect was Davis (1982) who discussed the strengths and 
weaknesses of first generation expert systems. But evolutions in expert systems technology are by 
necessity slow because it takes at least five years to construct a serious system. 

Second generation expert systems draw on a lot of recent work in A.I.. One source is the work on 
qualitative causal reasoning which provides ways to handle deep reasoning (see Bobrow and Hayes 
(1985) for a recent overview.) Another source is recent work on learning such as reported in the col- 
lection put together by Mitchell, Michalski and Carbonell (1984). Recent advances in the design and 
implementation of knowledge representation systems which have an open-ended set of formalisms and 
are capable of meta-representation and meta-reasoning are another enabling factor. 

The objective of this paper is to outline the components of a second generation expert system and to 
illustrate briefly how each of them works. The examples are drawn from one important application 
area, namely expert systems for repair and maintenance of technical systems. 

Technical systems, such as trains, computers, airplanes, power plants, or cars, are artefacts con- 
structed to perform a particular function. In contrast to biological or natural systems which formed 
the domain of most first generation expert systems, they are in principle completely understood. All 
components are known and the behavior of the whole can theoretically be predicted from the behavior 
of the parts. Maintaining technical systems involves diagnosing possible failures (or the potential for 
future failures) and planning and executing a sequence of repairs that will lead again to a functioning 
system. 

The repair and maintenance of technical systems is a skill that relatively few people possess. Skill is 
needed because technical systems are very complex. An exhaustive search of all possible things that 
could go wrong is typically out of the question. Also, because not every component is observable, 
reasoning has to proceed on the basis of weak and very partial information. 

The trouble-shooting of an ordinary car is taken here as specific application because many people 
have intuitions about it. Unfortunately, the exposition of the examples (which have all been imple- 
mented) has to be brief. Steels and Van De Velde (1985) contain more details. 

2. Components of a second generation expert system 

The kernel of an expert system consists of two components: A representational component and 
a problem solving component. Other components for communicating with the user, constructing expla- 
nations, gathering data, etc. are constructed around this kernel and will not be discussed in this 
paper. 

THE REPRESENTATIONAL COMPONENT 

The representational component has two subcomponents: A conceptual model and one or more factual 
models. The conceptual model delineates the basic entities in the universe of discourse, their possible 
properties and relations, as well as associated information like defaults, ways to compute certain pro- 
perties, ways to communicate with the user, etc. The factual model contains all the facts, intermediate 
hypotheses and final conclusions for a specific problem instance using the conceptualisations provided 
by the conceptual model. 
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The representational component is typically frame-based. Information is structured in units with vari- 
ous slots that hold information about the concept described by the unit. This information can be in 
the form of defaults, rules, procedures to compute information, etc. and is inherited by more specific 
units. 

PROBLEM SOLVING COMPONENT 

In first generation expert systems, the problem solving component consists solely of a collection of 
rules. A rule contains conditions (the IF-part) and inferences which can be drawn if the conditions are 
satisfied in the factual model under investigation (the THEN-part). Rules are typically structured in 
rule sets and their activation is guided by a control structure which selects what rule to explore in 
case more than one rule is applicable. Recently there has been a trend to let the components of a 
rule be richer in structure, so that the various functions of the conditions or the conclusions become 
explicit. Thus a diagnostic rule might have preconditions, typical symptoms, impossible symptoms, 
probable symptoms and necessary symptoms. See Clancey(1984) or Breuker and Wielinga (1985) for 
motivations and more examples. This finer structuring of a rule is also important for learning. 

In second generation expert systems there is an additional problem solving component which performs 
deep reasoning. In comparison to the heuristic rules, this component explores a much larger search 
space because the primitive operators reflect a more fundamental and deeper description of the 
domain. 

For many application domains a deep model is available. For example the anatomy and internal work- 
ing of many technical devices is entirely known because it has been designed. Therefore it is possible 
in principle to perform a thorough investigation. However such an investigation will be virtually 
impossible if a complex device is involved or if the cost of certain observations is very large. Hence 
a graceful performance degradation. 

THE LEARNING COMPONENT 

The discovery of heuristic rules as an outcome of deep reasoning requires a third component, the 
learning component. It has two important subcomponents: one that extracts rules from deep reasoning 
(the rule-extractor) and one that incorporates the rules in the existing rule-set (the rule-integrator). 
Other learning operations can be performed on rule-sets to derive new concepts or optimise the rule- 
set. 

TOOLS 

There is a growing number of commercially available tools to construct expert systems (see the over- 
view in Kinnucan, 1985). These tools range from relatively simple expert system shells which sup- 
port a particular rule formalism (such as the IF/THEN rules of OPS-5, Forgy (1981)), to sophisti- 
cated knowledge engineering environments. Second generation expert systems require the more 
sophisticated class of tools to implement and integrate their various components. 

First of all a variety of formalisms needs to be supported: Frame-structured representations to 
represent the models, rule formalisms to represent the heuristic knowledge, constraints to drive deep 
reasoning, etc. Moreover it must be possible to represent knowledge ABOUT each of these items, 
requiring the capacity for meta-representation and meta-reasoning. For example, it must not only be 
possible to represent and use heuristic rules, but also to represent facts or rules about the rules and 
reason explicitly over their structure. In addition, it must be possible to represent and reason expli- 
citly over deductions that have been made, new concepts that have been introduced, or questions that 
have been asked. 

Various knowledge representation systems now have the capability to perform these functions. In our 
own experiments we use the knowledge representation system KRS (Steels, 1984). 
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KRS is designed to support the definition and manipulation of concepts. Systems based on KRS (and 
indeed KRS itself) consist of nothing but concepts. Concepts are structured in inheritance hierarchies 
and have a number of associated concepts (called subjects). There is a graphical interface to browse 
through networks of concepts and to interactively construct or edit them (cfr. Figure 1). 

The construction of a specific application requires the introduction of domain concepts. But KRS also 
supports the definition and use of formal concepts. These are concepts about knowledge representation 
although defined and used in the same way as domain concepts. Thus there are formal concepts for 
keeping information, such as a relation-formalism, or a set-formalism. There are computational con- 
cepts to describe algorithms, and concepts defining knowledge representation formalisms like a rule, a 
logical implication, or a constraint. Control-structures and inheritence schemata are also described 
explicitly as concepts. 

3. The problem solving component 

3.1. The task 

A causal model consists of a set of properties of components which are causally related in the 
sense that the value of one property is determined by the values of one or more other properties. 
Some of these properties are observable, most of them are not or only with difficulty. Causal rela- 
tions can easily be represented in a network where the nodes represent the properties of the com- 
ponents. 

Figure 1 shows a causal network which is part of the system for starting a car. There are three 
requirements for an engine start. The starter must turn the engine, the two sparkplugs must fire and 
the starter-transmission must be okay. Each of these has a number of further enabling causes. 

The following task will be taken as example application: Given a technical device described as a net- 
work of causal relations between properties of components, given a state of the device and an 
anomalous property, i.e. a property whose observed value differs from the expected value, find an 
explanation either in terms of malfunctioning components or in terms of external controls that need to 
be changed. 

The task assumes a human (or computer) capable of observing properties and judging whether the 
property is supposed to be the way it should be based on a functional model. 

3.2. Heuristic rules 

It is easy to envisage heuristic rules for this task. For example, there might be rules like ”if the 
headlights are not on, check whether they have been turned on”, or ”if the lights cannot burn, the 
batteries are not charged”. Most user’s manuals contain such rules and even non-experts know at least 
some of them. 

3.3. Deep reasoning 

Alternatively it is possible to look at the detailed causal network of the car. We will give one 
example but other deep reasoning mechanisms would work equally well. Deep reasoning can be done 
using the following principles: 

1. If the effect of a property is normal, then there is reason to believe that it is itself normal. 

2. If the effect of a property is anomalous, it may itself be anomalous too. 

Thus if the engine is not starting and one of its causes is the presence of gas, then this property 
becomes suspect. 

A possible deep reasoning algorithm starts from an anomalous property and investigates the causes of 
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this property until observable properties are arrived at. The user is queried for these properties and if 
they are anomalous (i.e. different from his expectation), an explanation has been found. If they are 
normal (i.e. matching with the expectation) then the explanation for the original anomaly lies else- 
where. 

When none of the observed properties which ultimately caused the anomalous property were 
anomalous, the cause of the anomaly must lie somewhere in between. In other words, one of the 
internal components must be faulty. 

The number of faulty components can often be reduced if there are other observables who also were 
caused by the same properties. Consider for example, the following network which depicts the 
causes emanating from x, and y. 




D 



A 

E F 

X is anomalous and needs to be explained. E, F, B, and C are observable properties and they 
are all normal. So the explanation why X is anomalous must be because there is a faulty component 
in between. But if Y is also normal, it can be deduced that its cause, namely D must also be normal, 
and therefore the only possible explanation for the anomaly of X is that A is anomalous, i.e. the 
component of which A is a property must be malfunctioning. 

Let us consider an example where the network given earlier is examined because the starter is not 
turning. The other relevant observations are: 

Starter = Turning Is Anomalous 
Battery = Charged is Normal 
Contact = On is Anomalous 

Backward examination of the causes of Starter = Turning leads to Starter = Powered. This is not 
observable so the reasoner descends further in the network. The causes of Starter = powered are 
Battery = Charged and Contact = On. Battery = Charged is normal so that cannot provide the explana- 
tion for the original anomaly. On the other hand, Contact = On is anomalous, therefore an explanation 
has been found. 

3.4. Differences between heuristic rules and deep reasoning 

Based on the above discussion the differences between heuristic and deep causal reasoning 
become clearer. Thus, there could be a heuristic rule that says ’’when the headlights are not on, check 
whether they have been turned on”. A deep reasoning system would follow the causal connections 
starting from the headlights and would eventually arrive at the switch to turn them on, but it would 
possibly check many other things on the way or start wandering around in the causal network in 
directions that have little to do with the initial problem. 

So we see the following differences: 

Heuristic rules make shortcuts: intermediate steps are skipped because those steps are unlikely to lead 
to a quick solution of the problem. 
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Heuristic reasoning does not refer to the working of the internals of the system but associates a 
number of easy to make external observations with a plausible conclusion. 

A deeper causal model will be able to come to the same conclusion, but would in principle also 
examine many other things. Some of which might not be easy to answer without extra measuring 
apparatus. 

On the other hand the set of heuristic rules is necessarily incomplete because it would require a rule 
for every possible failure in the system and thus the power (in terms of efficiency in problem solving) 
obtained from heuristic rules would be lost. 

What we want of course is the best of both: use heuristic rules for common cases to get a quick 
solution to the problem but fall back on deep reasoning when the case is not covered by heuristic 
rules. This is precisely what a second generation expert system does. It makes it also possible to 
extract heuristic rules after a deep reasoning sequence has been done. The next section shows how. 

4. The learning component 

A deep reasoning sequence potentially investigates many causal connections and queries the user 
for a lot of observations. To be worthwhile, heuristic rules must do the opposite: They should be as 
simple as possible, leaving out all the details and all the observations that did not directly contribute 
to a solution of the problem. Extracting rules from deep reasoning is difficult because it is not obvi- 
ous which details are irrelevant. Steels and Van De Velde (1985) describe a technique, called rule- 
learning by PROGRESSIVE REFINEMENT, which addresses this issue. 

Initially a new rule makes as much abstraction as possible using circumscriptive reasoning (McCarthy, 
1983): Everything which is not mentioned in a rule is supposed to be irrelevant or normal. Later the 
conditions of a rule are progressively refined to discriminate with a new rule whose conditions over- 
lap but whose conclusions are different. Interestingly enough, this technique is monotonic. A learned 
rule never becomes invalid, although its applicability is restricted. 

We consider learning a particular type of rules (called solution rules) which have primary symptoms, 
secondary symptoms and corrected properties. The rule becomes active when all its primary symp- 
toms are present. Then the secondary symptoms are checked and when they are present as well, a 
number of properties are to be corrected. (Other construction procedures are needed for other types 
of rules although the principles remain the same). 

A rule can be extracted from a deep reasoning sequence as follows: 

1 . The primary-symptoms of the rule are equal to the anomalous property that triggered the deep rea- 
soning sequence. 

2. The corrected-properties are equal to the conclusions of the deep reasoning sequence, i.e. the list 
of properties which deep reasoning deemed ultimately responsible for the anomaly. It is assumed that 
a change of these properties either directly or indirectly causes the anomaly to disappear. 

3. The secondary-symptoms are initially empty. 

For example, after the first deep reasoning sequence discussed in the previous section, the following 
rule can be extracted: 

Rule-1 

Primary-symptoms: Not Starter = turning 
Secondary-symptoms: - 
Corrected-properties : Contact = on 



Clearly this is an extreme form of abstraction. It assumes that the encountered situation is the only 
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situation that can ever go wrong! The triggering symptom is therefore linked directly with the correc- 
tions that worked. 

New rules need to be integrated with already existing rules to make sure that they remain mutually 
exclusive, i.e. no two rules should fire and propose a different solution for the same primary- 
symptom. 

Rule-integration is trivial if the rules are orthogonal, otherwise the following procedure is used: 

1. The corrected-properties of the new rule are added as necessary symptoms of the old rules, unless 
the property is one of the corrected-properties of the old rule. 

2. The negation of the corrected-properties of the new rule is added as a secondary symptom of the 
new rule. 

The intuition behind this integration procedure is that symptoms are added from other rules to make 
sure that the rules remain mutually exclusive. The refinement process is monotonic and works also 
for rule chaining. 

For example, suppose we have a rule which says that the car should be put in parking mode when it 
does not start: 

RULE-2 

primary-symptoms: Not car = starts 
secondary-symptoms: - 
corrected-properties : mode - par ki ng 

Suppose there is now a new rule which says that there should be gas put in the car when the car 
does not start: 

RULE-3 

primary-symptoms: Not car = Starts 
secondary-symptoms: - 
corrected-properties : gas = present 
then the ruleset after integration looks as follows: 

RULE-2 

primary-symptoms: not Car = Starts 
secondary-symptoms: gas = present 
corrected-properties : mode = parking 

RULE-3 

primary-symptoms: not car = starts 
secondary-symptoms: not gas = present 
corrected-properties : gas = present 

The rules now say: if the car does not start and there is gas present, put the car in parking mode. If 
the car does not start and there is no gas present, make gas be present. 

If a new problem is posed to the system, The rules constructed following the above procedure are 
tried before any deep reasoning is done. If a rule .fires because the primary-symptom and the 
secondary-symptoms have been observed, then the corrected-properties are tested out in the model and 
it is investigated whether their correction indeed resolves the initial anomaly. If this is the case then 
the rule is confirmed and no changes need to be made. If not, deep reasoning is started again to per- 
form a more thorough diagnosis. From the result a new rule can then be extracted and incorporated. 

FURTHER LEARNING 

Although the ruleset obtained through the above construction process will progressively solve more 
and more problems, it is far from efficient. Rules that partially overlap remain independent, the same 
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conditions will be checked many times over, etc. Therefore other construction procedures are intro- 
duced that operate once the initial rulesets have been formed. Here are some example: 

+ LEARNING THROUGH RULE COMBINATION 

Rules that have structure in common can be combined. For example, if two rules have the same set 
of corrected-properties, then a new rule may be generated with a combination of primary symptoms 
and secondary symptoms. 

+ LEARNING THROUGH GENERALISATION 

Deep reasoning typically takes place over a small part of a complex system. Often there are other 
portions of the same device (or different devices) which have the same causal structure. By making 
abstraction of the specific area for which it was discovered, rules get a wider applicability. If the 
causal structures are not equal but similar, then further learning through adaptation can refine the 
ruleset acquired elsewhere. 

+ LEARNING NEW CONCEPTS 

A subset of the necessary symptoms may be common to many rules. In such cases it is possible to 
introduce a new concept which can be used to formulate an intermediate conclusion. It will be more 
efficient to first establish this intermediate conclusion, instead of reconsidering all of its components. 
The new concept can also be used to enrich the model of the device. 

+ LEARNING THROUGH RULE-ORDENING 

The ruleset needs to be restructured so that rules are ordered. This leads to greater efficiency 
because symptoms present in more than one rule are not investigated more than once. The ordening 
itself again depends on experience, so that rules covering situations which are more frequent get 
priority. 

+ GROUPING OF RULES 

Another important form of learning is the division of rules in smaller sets and the learning of rules 
that lead from one set to another set. This division can often be based on the underlying model. 

5. Conclusions 

A second generation expert system not only uses heuristic rules, but has also a model of the 
domain so that deeper reasoning is possible if the rules are inadequate. This leads to a graceful per- 
formance degradation instead of an abrupt failure if there is no rule covering a particular situation. It 
also leads to a new way of doing knowledge acquisition by extracting rules from experience in solv- 
ing a particular problem. 

The state of the art in Artificial Intelligence is sufficiently advanced to realise second generation expert 
systems. Our own experiments in the domain of diagnosis of technical systems have confirmed the 
feasibility. 
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